タイムラインで、あるGoogleエンジニアの動画が流れてきました。
IDEを削除しなさい、もう必要ないよ。2026年になってもまだAIエージェントを構築していないなら、あなたがどれだけ遅れているか、信じられないほどだ
Googleでは、エンジニアの85%がエージェント的なループとグラフを実行している、それが今のエンジニアリングのセットアップの姿だ
30年の経験を持つエンジニアが25分かけて、2026年のエンジニアリングの方向性を語っているという触れ込みでした。
煽り文句には距離を置きたい
正直なところ、最初に引っかかったのは中身より言い回しのほうでした。「これをスキップしたら取り残される」「絶対に見逃せない」「見た後はステップバイステップガイドでさらに進もう」。この手のフレーズの並びは、内容の正しさとは別に「凄そうに見せたい」インセンティブが働いているサインだと、最近読んだ記事でも指摘されていました。
「エンジニアの85%」という数字も、誰がどう調べたのかがわからないまま独り歩きしています。AIによる生産性向上の報告は販売促進が目的であることが多いので、まず発信者のインセンティブを疑うくらいがちょうどいい、という話も別の記事で読んだばかりでした。数字そのものより、数字を出してくる文脈のほうを見るべきだと思っています。
それでも「ループとグラフ」という語彙自体は本物
一方で、「エージェント的なループとグラフ」という言葉自体は、煽りとは別に実体のある話だと感じています。
ループエンジニアリングは、1つのエージェントが1つのことを試し、確認し、調整する反復を人間が設計する仕事です。グラフエンジニアリングは、その単体のループを束ね、複数のサイクルが互いを監視・修正し合うネットワークとして設計する考え方を指します。目新しい発明というより、数十年クリティカルシステムを支えてきたグラフ理論に新しい名前がついたもの、という見方のほうがしっくりきます。
語彙自体はシンプルです。1エージェントが1つのタスクをこなし、1つの入力から1つの出力を生む「ノード」。あるジョブが別のジョブの出力を実際に必要とすることを示す「エッジ」。ノードの契約は、3語以内で言える単一の仕事、明示された入力、モデルの解釈なしに分岐できる構造化された出力、そして失敗を値として扱う名前付き失敗状態の4要素で定義できます。失敗が値として扱われていれば、グラフは止まらずに迂回できます。
覚えるべき形も、実質は「ダイヤモンド」1つです。分岐して複数のワーカーが並行して集め、コードで圧縮し、最後に1エージェントが統合する。直列に書いた40ステップのワークフローは40個の逐次故障点を抱えますが、本当に依存している関係だけを残してグラフに描き直すと、最も遅い層の速度で完了するようになります。
IDEを削除する、はどこまで本当か
ここまで見ると、「85%」という数字の真偽はともかく、AIエージェントのループやグラフを設計する仕事が増えていること自体は、誇張なしに納得できます。ただそれは「IDEが要らなくなる」という話とは、少し次元が違う気もしています。
ノードの契約を書く、偽エッジを見つけて依存関係を削る、失敗状態を値として設計する。これらは結局、コードやスキーマとして書き下ろす作業です。エディタが要らなくなるというより、エディタで書く対象が「1行1行のロジック」から「ノードとエッジの設計図」へ移っていく、という理解のほうが自分の実感には近いと感じます。
この語彙の広まりには懐疑的な反応もあります。「通常業務でループを構築している人などいない」「コストがかかりすぎる」という批判は、煽り文句への違和感とは別に、技術的な実感としてもうなずけるところがあります。
まとめ
- 「見逃せない」「取り残される」といった煽り文句と、内容の正しさは別軸で見る
- 「エージェント的なループとグラフ」という語彙自体は、グラフ理論の再命名として実体がある
- ノード・エッジ・契約・ダイヤモンドという4つの部品で、ほとんどの設計は説明がつく
- IDEが消えるというより、エディタで書く対象が個々のロジックから設計図へ移っていくと捉えるほうが実感に近い
煽りに乗るのではなく、まずは自分の手元の小さなワークフローを、偽エッジがないかという目で1つ描き直すところから試してみます。
参考