現場の「うんざり」がプロダクトになる — BASEの起源とスタートアップの逆張り戦略

BASEが打ち出した「初期費用0円・月額0円」のECプラットフォームは、2012年当時の業界常識を覆すものだった。なぜそのモデルが可能だったのか。その背景にはリアルな現場課題を直視した、シンプルな逆張り戦略があった。 BASEの原点 — 「高すぎる」を解決する BASEの創業者・鶴岡裕太さんがネットショップ作成サービスを作ろうと思ったきっかけは、大分で洋品店を営む母親が「ネットショップを開きたい」と言ったことだった。しかし既存のEC構築サービスには初期費用数十万円・月額数万円の壁があり、個人商店には手が届かなかった。 ここで重要なのは、このきっかけが「崇高なビジョン」ではなく、身近な人の具体的な不満から始まっている点だ。 世界を変えたい → ❌ 革新的なSaaS → ❌ IPOしたい → ❌(少なくとも初期は) あったのは「非エンジニアでもECを作れるようにしたい」という、ごく素朴な動機だった。 「初期費用0円・月額0円」を可能にした逆張り 当時のEC構築市場の相場は、初期費用数十万円・月額数万円が当たり前だった。BASEが打ち出した「初期費用0円・月額0円」は、競合にとって信じがたいモデルだったはずだ。 BASEは商品が売れたときにのみサービス利用料(3%)と決済手数料(3.6%+40円)が発生する収益モデルを採用した。「ユーザーが稼いだときだけ一緒に稼ぐ」という構造だ。 提供側はリスクを取ることになるが、ユーザーには「失敗してもタダ」という参入障壁の除去をもたらした。これが個人商店・スモビジへの一気の普及を後押しした。 受託→プロダクトという転換パターンの普遍性 「まず受託でキャッシュを稼ぎ、そこからプロダクトへ転換する」というパターンは、多くの日本のスタートアップが実践している。 チームラボ(2001年創業): 初期はWebサイト制作などの受託開発を主力に据えながら事業基盤を固めた SmartHR: 前身のKUFUが「受託70%・自社サービス10%」という比率でスタートし、SaaSへと転換した 「まず受託でキャッシュを稼ぐ」という選択肢は、決して逃げではない。現場で繰り返す作業の中にこそ、プロダクトの種がある。 現場の「うんざり」は設計図になる スタートアップの教科書には「大きなビジョンを持て」と書いてある。しかし現実に強いプロダクトを作るのは、現場の「これ、なんとかならないか」という感覚だ。 自分の親が直面した不便、繰り返される問い合わせ、毎回同じ設定をゼロからやり直す徒労感——等身大の課題を解決するプロダクトは、ユーザーインタビューを重ねて作られた「仮説」とは別の強さを持つ。 あらゆる現場の「うんざり」は、プロダクトの設計図になりうる。 Source: X (Twitter) @RrrrrKayuy620

2026年5月11日 · 1 分

HubSpot を Claude Code から操作する 6 つの認証方式の違い — Private App / OAuth / MCP / PAK / Developer Key / Service Key

HubSpot は API 認証の選択肢が多く、「結局どれを使えばいいのか」が混乱しがちです。特に Claude Code から HubSpot を操作したい場合、現在は 6 種類の認証手段が併存しています: 非公開アプリ(Private App) 旧 API キー(廃止済み) MCP 認証アプリ(HubSpot 公式 MCP Server) パーソナルアクセスキー(Personal Access Key) 開発者 API キー(Developer API Key) サービスキー(Service Key、新規 Beta) この記事では、それぞれの違い・推奨用途・Claude Code から使う場合の選び方を整理します。なお旧 API Key は廃止済みですが、参考情報として記事末尾で触れます(実質的な選択肢は 6 つです)。 結論を先に言うと: 用途で 2 軸に分かれます。 アドホックに自然言語で操作したい(営業・マーケが Claude Code から HubSpot を触る等) → 公式 MCP サーバー 本番運用・バッチ・Webhook など継続的なシステム統合 → REST API 直叩き + Service Key(新規)/ Private App(既存) 両者は競合ではなく補完関係で、実務では併用するのが現実解です。 早見表 認証方式 用途 スコープ トークン寿命 状態 Claude Code から使うなら HubSpot MCP Server(公式) AI エージェントから HubSpot 操作 アプリと同等 OAuth ベース ✅ 2025-2026 リリース ✅ 最も推奨(1 行で接続) Service Key(新) システム間データ連携 アカウント単位の細かい権限 永続 ✅ 2026-02-10 Public Beta ✅ Private App の後継、新規ならこれ Private App 単一アカウント向け統合 アプリ単位で細かく設定 永続 ⚠️ 維持されているが、新規は Service Key 推奨 ✅ シンプルな REST 呼び出し OAuth 2.0(Public App) Marketplace アプリ・複数アカウント scope ベース access 30 分・refresh で更新 ✅ 公式・現役(v3 が新版) △ 自前で OAuth フロー実装が必要 Personal Access Key(PAK) HubSpot CLI 認証 アカウントごと 永続(rotate 可能) ✅ 現役 △ CLI 経由の操作のみ Developer API Key Developer Account 内のアプリ管理 開発者アカウント全体 永続 ✅ 現役 △ アプリ管理用、CRM データには不向き 旧 API Key(参考) 単純な API 呼び出し アカウント全体 永続 ❌ 2022-11-30 廃止 ❌ 使えない 各認証方式の詳細 ① 旧 API Key(廃止済み、参考情報) HubSpot ポータルの「Integrations → API Key」から発行できたアカウント単位の単一キー。 ...

2026年5月9日 · 14 分

S&P500のコールオプション出来高が史上最高の2.6兆ドル — ガンマ・スクイーズが市場をカジノ化する仕組みと崩壊リスク

2026年5月7日、S&P500のコールオプション1日の出来高が米国株式市場の歴史上初めて2.6兆ドルに達した。この数字が意味することと、その裏に潜む「ガンマ・スクイーズ」と呼ばれる爆発的なリスクについて解説する。 2.6兆ドルとは何か 2.6兆ドルは実際の株式購入額ではなく、コールオプションの名目元本の合計だ。個人投資家とトレーダーが「コールオプション」を爆発的に買い漁っている規模を示す数字である。 コールオプションとは、少額の資金で株価の上昇に賭けるデリバティブ商品だ。賭けが当たれば数倍のリターン、外れれば全額失う仕組みである。米国株が連日新高値を更新する中、多くの投資家が「まだ上がる」と信じてオプションを買い続けている。 ここで問題が生じる。そのオプションを売っているのは誰か。 答えはマーケットメーカーだ。 マーケットメーカーの行動とガンマ・スクイーズ マーケットメーカーはオプションを売ると、株価上昇リスクを自分が負うことになる。これをヘッジするため、オプションの「デルタ値」(0〜1の間で変化)に応じた量の株式を購入しなければならない。 投資家がコールオプションを買う マーケットメーカーはデルタ値に応じた株をヘッジ購入(株価が上がるほどデルタは増加) 株価が上がるとデルタが大きくなり、さらに多くの株を追加購入する 2.6兆ドルのオプション買い注文の裏側には、このデルタ・ヘッジによる天文学的な規模の株式買い注文が継続的に発生する。これは企業の業績や経済の強さとは無関係に、オプション市場がマーケットメーカーに株を強制購入させている構造だ。 この現象を「ガンマ・スクイーズ」と呼ぶ。 このフィードバックループが加速すると、相場は天井知らずに急騰する。最近のS&P500が連日新高値を更新している真相は、企業業績の好調ではなく、このオプション市場の構造的な買い圧力にある。 市場はギャンブルに変わっている 本来の株式市場における「価格付け(ファンダメンタル分析)」とは何か。企業の収益力・成長性・競争優位性を分析し、合理的な株価を算出することだ。 だが現在の市場は違う。誰も企業の本質的な価値を問わない。「明日上がるか」という一点に全員が賭けている。 コールオプション出来高が歴史的な記録を更新したことは、市場が完全にカジノ化した証左だ。個人投資家も機関投資家もヘッジファンドも、全員が賭け金を積み増している。 2.6兆ドルのオプション名目元本は、2.6兆ドル規模の賭けが積み重なっていることを意味する。賭け金が増えるほど相場は狂乱し、相場が狂乱するほど賭ける参加者が増える悪循環だ。 この構造は2015年の中国A株レバレッジ相場(信用取引の急拡大で上海総合指数が半年で約150%急騰後、1カ月で40%以上暴落した相場)と本質的に同じだ。どちらも実際の価値ではなく、「お金がお金を呼ぶ」メカニズムで動いている。 崩壊はいつか 誰にも正確な時期はわからない。ただし、オプションには必ず満期日がある。 満期日を迎えると: 上昇に賭けた投資家がポジションを閉じる マーケットメーカーも同時にヘッジ・ポジションを解消する これまで株価を支えてきたデルタ・ヘッジの買いが消滅し、下落圧力が働く 上昇が激しければ激しいほど、満期時のヘッジ解消による下落圧力も大きくなる。 過去の事例: 事例 時期 経緯 GameStop 2021年1〜2月 ガンマ・スクイーズとショート・スクイーズが複合し、株価が約17ドルから483ドルに急騰、その後40ドル台、さらに25ドル台へと暴落 Tesla 2020〜2021年 オプション市場の異常な買いがバリュエーションを急騰させ、2022年にピーク比約65〜70%の大幅下落 現在のS&P500はGameStopを100倍に拡大したものと見ることができる。2.6兆ドルのオプションの満期が集中する局面、または大規模な一括決済が走る局面が、この「爆弾」が爆発するタイミングだ。 そして爆発の前に、誰かが事前に警告してくれることはない。 長期投資家へのメッセージ 米国株市場には優れた企業が多く存在し、実態経済に根ざした本物の成長もある。長期的な強気見通しを否定するものではない。 しかし現在の相場は、企業のファンダメンタルズとかけ離れたところで動いている。 レバレッジをかけ、借入を抱え、手元キャッシュも持たずに追いかけ買いをしている投資家には、一つの問いを投げかけたい。 「爆弾はいつ爆発するか」ではなく、「爆発した時に自分がその船に乗っているか」を問え。 上昇の加速力は下落の加速力と同じ大きさだ。ポジションサイズと現金比率の管理こそが、今の市場で最も重要なリスク管理である。

2026年5月9日 · 1 分

Apprise + シフト管理ツールで OnCall 自作スタックを組む — PyShift・OR-Tools・GoAlert の役割と選び方

前回の記事で「Apprise + 自作 Web サービスで OnCall 相当を組む」例を示しました。この記事ではよくある誤解を整理し、シフト管理を含めた自作 OnCall スタックの現実的な選択肢を深掘りします。 まずは Apprise の正しい位置付けを確認 Apprise は名前から「シフト管理ができそう」と誤解されがちですが、実際の役割は明確に分かれています。 正しい位置付け: Apprise は 「通知の超便利ハブ」 — 1 つのコードで Slack / メール / SMS / LINE / Telegram など 100 種類以上の通知先に統一インタフェースで送る シフト管理機能(カレンダー、ローテーション、当番判定)は持たない 「シフト管理に Apprise を使う」とは、シフトロジックは別のライブラリ / DB / カレンダーで持ち、通知配信だけ Apprise に任せるという意味 つまり Apprise は「組んだシフトを確実に届ける道具」であり、「シフトを組む道具」ではありません。前回記事のコード例で get_policy_for_now() を Python で書いていたのは、まさにこの「シフト判定ロジックを自作」の実装です。 シフト管理を「自作する場合」に組み合わせる Python ライブラリ シフトロジックを自分で書くなら、以下のライブラリが Apprise と相性が良い。 1. PyShift(point85/PyShift) — 古典的なシフトローテ point85/PyShift は、Java 版の Shift ライブラリを Python に移植したもの。PyPI では PyWorkShift として配布されています。 ...

2026年5月8日 · 7 分

Claude Code はなぜ事前登録なしで MCP に繋がるのか — RFC 7591 Dynamic Client Registration と連動 RFC 群

個人開発アプリの認証は「絶対に」WorkOS を使え — MCP 化で知った最強の選択肢 では、WorkOS AuthKit の Dynamic Client Registration(DCR)対応が MCP 認証の決め手になる、という話を書いた。 MCP × OAuth 2.1 の全体像は MCP のセキュリティが OAuth 2.1 で大幅進化 で扱った。本記事はその中で SHOULD/MAY 扱いされている DCR を仕様レベルで深掘りする補足記事だ。 具体的には、DCR を定義する RFC 7591 そのものの仕様と、MCP 認証で必ず連動する周辺 RFC 群(9728 / 8414 / 9068 / 8707 / 7636)の関係 を、Claude Code の自動ログインフローを追いながら整理する。 この記事でわかること: なぜ事前登録なしにクライアントが認可サーバーに繋がってくるのか(RFC 7591 / 9728 / 8414 の連動) Claude Code の自動ログインフローを HTTP リクエスト単位で何が起きているか なぜ JWT の audience 検証で詰まるのか(RFC 9068 / 8707 と DCR の構造的な相性問題) なぜ MCP では Dynamic Client Registration(DCR)が必要なのか 従来の OAuth 2.0(RFC 6749)は、クライアント(アプリ)を事前に手動登録する 前提だった。Google や GitHub の OAuth を使うときに、開発者が「アプリを登録 → client_id と client_secret を発行 → コードに埋め込み」という流れだ。 ...

2026年5月8日 · 6 分

Claude Opus超えの新LLM「SubQ」— Subquadratic Sparse Attentionで1200万トークンを実現、コスト1/5に

2026年5月5日、マイアミのスタートアップ Subquadratic が、業界に衝撃を与える新LLM「SubQ」を発表した。キャッチコピーは「Claude Opus超え」。1200万トークンのコンテキスト長、競合比1,000倍のコンピュート削減、1/5以下のコスト——数字だけ見れば夢のような話だ。しかし果たして実態はどうなのか、技術的な仕組みから現時点の課題まで整理する。 SubQとは何か SubQは、Subquadratic Sparse Attention(SSA) と呼ばれる新しいアテンション機構を採用したLLMだ。開発したのはフロリダ州マイアミ拠点のスタートアップ「Subquadratic」で、CEOはJustin Dangel(5回連続起業家)、CTOはAlexander Whedon(元Meta、元TribeAI生成AI部門長)。 2017年のTransformer論文以来、すべての主要LLMはアテンション計算のコストがコンテキスト長の2乗に比例するという「二次スケーリング問題」を抱えてきた。長いコンテキストを扱おうとすると、RAGによるチャンク化・ベクトルDB検索・要約ループといった「誤魔化し」が必要になる理由がここにある。SubQはこの根本問題を解決したと主張している。 Subquadratic Sparse Attention(SSA)の仕組み 従来の密なアテンション(Dense Attention)では、あるトークンが他のすべてのトークンと比較される。コンテキスト長Nに対してコストはO(N²)となり、Nが大きくなるほど指数的に重くなる。 SSAはこれを根本から変える。各クエリトークンに対して、実際に重要な位置だけを選択し、その部分集合についてのみアテンション計算を行う仕組みだ。 標準Transformer: 全N個のトークンを全N個と比較 → コストO(N²) SSA: クエリごとに重要な位置k個を選択してアテンション計算 → O(N×k) kがNに対して十分小さければ → 実質O(N)(線形スケーリング) DeepSeekなどの既存スパースアテンション手法との違いも強調されている。DeepSeekのアプローチはアテンション計算のインデックス構築自体に二次コストが残るのに対し、SSAはその構築コストも線形に抑える設計だという。ただし詳細な技術仕様は非公開のため、この主張は現時点で独立検証できない。 主な性能指標 Subquadraticが公表している数値は以下のとおり。なお、これらはすべて同社による自社計測であり、独立検証は未実施である点に留意が必要だ。 指標 SubQ 比較対象 コンテキスト長(本番API) 100万トークン Claude Opus 4.7: 100万 コンテキスト長(研究用) 1200万トークン Opus 4.7の12倍 速度(1Mトークン時) FlashAttention比 52倍高速 — スループット 150 tokens/秒 — コスト(1Mトークン処理) 約$8 最先端モデル: 約$2,600 コンピュート削減(12Mトークン) 競合比 約1,000倍削減 — コスト面では「Claude Opusの約1/5」と説明されており、長文コンテキスト処理において経済的に圧倒的な優位性を主張している。 ベンチマーク結果 長文コンテキスト評価として注目されているのが MRCR v2(Multi-needle Retrieval and Context Reasoning)だ。複数の情報を長いコンテキストから正確に取り出す能力を測るベンチマークで、長文処理の実力差が出やすい。 ...

2026年5月8日 · 1 分

Grafana OnCall は終わった、Grafana Cloud IRM が始まった — オンコール体制の現代的選択肢を整理する

前回の記事で「サーバー監視の王道スタック」として Prometheus + Loki + Grafana + Alloy を整理しました。アラート設計のセクションで触れた Grafana OnCall について、改めて単独で深掘りします。 ただし重要な注意点があります — Grafana OnCall OSS(grafana/oncall リポジトリ)は 2026 年 3 月 24 日にアーカイブされました。後継は **Grafana Cloud IRM(Incident Response Management)**で、OnCall と Incident の両アプリが 1 つに統合されています。 「Grafana OnCall を新規導入したい」「既存環境を移行すべきか」という人に向けて、何が終わって、何が始まったのかを整理します。 Grafana OnCall とは何だったのか Grafana OnCall は 「アラートが鳴った後の対応フロー」を管理するツールでした。 Prometheus / Loki / Grafana が「異常を検知する」までを担当 Grafana OnCall は「鳴ったアラートを誰に・どうやって届け、どう対応するか」を管理 PagerDuty や Opsgenie の OSS 互換ツールとして、Grafana エコシステムの中で重要なポジションを占めていました。 主な機能(当時) アラートの集約とルーティング — 複数の監視システムからのアラートを統合、内容に応じてチームへ振り分け オンコールシフト管理 — 担当者のカレンダー(シフト表)に従って当番者にだけ通知 エスカレーションポリシー — 一定時間応答がなければ次の担当者へ自動エスカレーション ChatOps 連携 — Slack / Telegram 上でアラート確認・対応開始(Acknowledge)・解決(Resolve)が完結 柔軟な通知手段 — Slack / Microsoft Teams / SMS / 自動音声通話(電話)/ モバイルプッシュ IaC 対応 — Terraform プロバイダで設定をコード管理可能 連携先(インテグレーション) カテゴリ 代表的な連携先 監視・アラート検知 Grafana, Prometheus (Alertmanager), Datadog, Zabbix, AWS CloudWatch, New Relic 通知・コミュニケーション Slack, Microsoft Teams, Telegram, SMS, 自動音声通話 OSS 版で自社サーバーに構築することも、Grafana Cloud のマネージドサービスとして利用することも可能でした。 ...

2026年5月8日 · 8 分

現代的サーバー監視の王道スタック — Prometheus + Loki + Grafana + Alloy で始めるオブザーバビリティ基盤

サーバー監視は「死活監視 + リソース監視」の時代から、「メトリクス + ログ + トレース」を 1 つの画面で相関分析するオブザーバビリティの時代に移りました。クラウドネイティブ環境では、Grafana Labs の OSS スタック(Prometheus + Loki + Grafana + Alloy)が、コスト・自由度・運用ノウハウの蓄積において事実上の王道になっています。 この記事では、なぜこの組み合わせが現代の標準なのか、各コンポーネントがどう役割分担しているのか、そして最小構成から本番運用までの全体像を整理します。 なぜこの構成が「王道」なのか サーバー監視の選択肢は大きく分けて 3 系統あります。 カテゴリ 代表例 特徴 OSS スタック(Grafana Labs) Prometheus + Loki + Grafana + Alloy 無料、自由度高、運用責任は自分で OSS スタック(Elastic) Elasticsearch + Logstash + Kibana + Beats 全文検索が強力、コストとリソース消費が大 SaaS Datadog、New Relic、Grafana Cloud 楽だが高価、データ主権がない このうち Prometheus + Loki + Grafana + Alloy が王道とされる理由: ...

2026年5月8日 · 11 分

macOS キャッシュ掃除チートシート — 開発マシンの数百 GB を取り戻す

開発マシンを放置していると、パッケージマネージャやコンテナ、IDE のキャッシュが気づかないうちに数百 GB に膨れ上がります。本記事では、主要なツールごとにキャッシュを安全に削除するコマンドをまとめます。 パッケージマネージャ系 Python 環境の uv は特に溜まりやすく、100 GB を超えることもあります。 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 # uv (Python) — 100 GB+ 溜まることも uv cache clean # npm npm cache clean --force # pnpm pnpm store prune # Yarn yarn cache clean # pip pip cache purge # Poetry — `poetry cache list` でキャッシュ名を確認してから個別削除も可能 # 下記の "." は全キャッシュソースを対象にする引数(Poetry バージョンによっては要確認) poetry cache clear --all . # Homebrew — ダウンロード済みアーカイブ brew cleanup --prune=all コンテナ・仮想化 Docker は数百 GB になりがちです。OrbStack / Docker Desktop どちらでも同じコマンドが使えます。 ...

2026年5月7日 · 2 分

バイブコーディングとエージェンティックエンジニアリング — AIの進化で崩れる境界線をSimon Willisonが考察

AIを使ったソフトウェア開発が急速に普及する中、「バイブコーディング」と「エージェンティックエンジニアリング」という2つのアプローチの境界線が曖昧になりつつある。Simon Willisonがこの問題を鋭く考察した記事が話題を呼んでいる。 バイブコーディングとエージェンティックエンジニアリングとは AI開発の文脈で、2種類のアプローチが対比されることが多い。 バイブコーディング(Vibe Coding) コードを深く読み込まず、AIの出力をそのまま使う開発スタイル。主に個人プロジェクトや試作品向けとされてきた。コードの内容を理解しなくても動くものが作れる、いわば「感覚」で進める手法だ。 エージェンティックエンジニアリング(Agentic Engineering) AIを強力なツールとして活用しつつ、プロのエンジニアが責任を持ってコードをレビューし、本番環境に耐えうるシステムを構築するアプローチ。品質・セキュリティ・保守性への意識が高い。 以前は「バイブコーディング=個人・試作」「エージェンティックエンジニアリング=本番」と明確に区別できた。しかし、AIの性能向上により、その境界線が揺らいでいる。 「もうコードを一行ずつ読まなくなった」という告白 Simon Willisonは自身の経験として、本番向けのコードでさえ、AIが書いたものを一行ずつレビューしなくなってきていると率直に認めている。 Willisonはこう述べる。Claude Codeに「JSON APIエンドポイントを作って」と頼めば、正しく実装してくれる——それはもう分かっている、と。 これは、大企業で別チームが開発した機能を、中身をほとんど確認せずそのまま使う感覚に近い。AIをある種のブラックボックスとして扱い始めているということを意味する。 人間のチームとの違いは「責任」にある。別チームの開発物には担当者がいて、問題が起きれば責任を取る人間が存在する。しかしAIには責任を取る能力がない。この非対称性が、Willisonに居心地の悪さを感じさせる根本的な理由だ。 AIの信頼が油断を生む 問題はさらに深い。AIが問題なくコードを書き続けることで「このAIは信頼できる」という過信が生まれる。そしていつか、本当は慎重であるべき場面でAIを過信して失敗するリスクが高まっていく。 また、AIの普及でソフトウェアの品質評価基準そのものも変化している。 従来: 充実したテストスイート、丁寧なドキュメント → 高品質の証明 現在: AIを使えばテストもドキュメントも数十分で完璧に揃えられる 見た目の完成度はもはや品質の指標にならない。代わりに価値を持ち始めたのは「実際に誰かが数週間・数ヶ月にわたって日常的に使っている」という実績だ。 開発プロセスの重心がシフトする @iwashi86 の整理によれば、AIによってコーディング速度が10倍(Willlison の元記事では「1日200行→2000行」)に跳ね上がったことで、従来のソフトウェア開発プロセス全体に変化が生じている。 コードを書くコストが劇的に下がったことで、失敗を恐れずに大胆なアーキテクチャ変更や仕様変更を試せるようになった。以前は実装コストが高すぎて試せなかったアイデアを、気軽にプロトタイプできる環境が整いつつある。 これはボトルネックを「実装」から「設計・判断・文脈理解」へとシフトさせることを意味する。 ソフトウェアエンジニアという職業の未来 Willisonは、AIが自動でコードを書く時代になってもソフトウェアエンジニアという職業は脅かされないと考えている。 その理由はシンプルだ:ソフトウェア開発はそもそも非常に困難な作業だから。AIはプロのエンジニアが持つ経験・判断力・文脈理解を増幅する道具にすぎない。AIを使いこなすためにこそ、深い専門知識が必要になる。 そして最終的には、企業も個人も「素人がAIで自作したシステム」より「プロがAIを駆使して作り上げた、実績のある製品」に対してお金を払いたいはずだ、とWillisonは結論づける。 まとめ Simon Willisonの考察は、AI開発ツールの急速な進化がエンジニアの「当たり前」を静かに書き換えていることを示唆している。 バイブコーディングとエージェンティックエンジニアリングの境界は、AIの性能向上とともに溶けつつある AIへの依存は「責任の所在」という根本的な問題を内包している ソフトウェアの品質指標は「見た目の完成度」から「実績・継続使用」へ移行しつつある 開発ボトルネックは「実装」から「設計・判断」へシフトしている それでもプロのエンジニアの価値はなくならない — AIはあくまで増幅器だ 元記事: Vibe Coding and Agentic Engineering Are Getting Closer Than I’d Like ツイート: @iwashi86

2026年5月7日 · 1 分