AIエージェントのためのグラフエンジニアリング：プロンプトとループからワークフローへ、という記事 towardsdatascience.com/graph… ・AIに仕事を任せるとき、1つのエージェントに全部やらせず、誰がどの順で作業してどこで確認するかを人が先に決めておく「グラフエンジニアリング」を、1つの例を通して説明する記事 ・2026年半ば、Hamel Husain氏がXで「ループエンジニアリングは終わった。次はグラフエンジニアリングだ」と書いて話題になった 【ほかの手法との違い】 ・プロンプトエンジニアリングとコンテキストエンジニアリングは、1回の応答でモデルに何を言い、何を見せるかの工夫。ループエンジニアリングはツールやメモリを与えて繰り返し作業させるが、次に何をするかはモデルが決める ・グラフエンジニアリングでは、次に何をするかをワークフロー側が決める。モデルは判断が必要なステップだけを受け持つ 【これまで：1つのエージェントに全部任せる】 ・例は「Shopifyの店舗向けにAI経理ツールを作るべきか」。AIに聞くと、市場や競合、販売計画まで入った立派なメモが返ってくる ・だが実際は、1つのモデルが調べる対象を決め、証拠を集めて解釈し、提案し、その自信の度合いまで自分で判定している。最初の方向が正しいか、どこで推論を間違えたかを途中で誰も確認していない ・実際のシステムでも、同じ手順を繰り返してはまる、業務ルールを見落とす、途中でコンテキストがあふれる、といった問題が起きる。筆者の答えは、より良いプロンプトではなく、1回あたりの仕事を小さくすること 【グラフにすると：同じ問いを役割に分ける】 ・計画役が問いを「顧客の困りごと」「競合」「販売経路」の3つに分け、3つの調査役が同時に調べて、結果を共有の記録（ステート）に書き込む ・懐疑役が、どの主張が証拠で裏付けられているかを確かめ、まとめ役が残った証拠だけで提案を書く ・懐疑役は下書きも見直す。「店舗は月50ドル払う」という主張に根拠がなければ、根拠を示すか削るよう差し戻す。往復は2回まで ・最後に創業者本人が提案と根拠を見て、実行するかを決める。顧客へのメールや公開投稿のように取り返しがつかない操作なら、実行の直前で必ず止める ・この1つ1つの作業がノード、次にどこへ進むかの決まりがエッジ。ノードはモデルとは限らない。請求額が承認の基準を超えるかの判定のように、分かっている業務ルールは普通のコードに書き、モデルには曖昧な情報の解釈や比較だけをさせる 【5つの型の使いどころ】 ・連鎖：前のノードの出力だけを次に渡す。まとめ役は懐疑役の判定リストだけを受け取るので、調査中の脱線（QuickBooks連携の話や関係の薄い掲示板など）を読まずに済む。次のノードが前の情報を全部必要とするなら、分けても得はない ・振り分け：「今のツールに請求書の同期機能を足すべきか」のような狭い問いなら、調査役1人に直接回す。広い問いを狭いと誤判定すると、調査不足のまま自信ありげな答えが出るので、迷ったら広い経路に回す ・並列化：上の3つの調査のように、互いの結果を必要としない作業は同時に回す。ある調査が別の調査の結果を待つなら並列にしない ・オーケストレーターと作業役：競合アプリ、経理代行、表計算のテンプレートなど、比べるべき代わりの手段がいくつあるか事前に分からないときは、オーケストレーターが先に洗い出して作業役を必要な数だけ作る。40件も同時に走らせると利用制限や予算を超えるので、上限を決めておく ・評価と改善：上の「月50ドル」の差し戻しがこれ。回数の上限に加えて、同じ主張を言い換えるだけになったら止める仕組みが要る 【自動化の前に手で試す】 ・LangGraphなどのツールに飛びつく前に、出力を1文で決め（例：このアイデアを試す価値があるかの1ページの提案）、有能な人がやる作業を5〜7個挙げて依存関係を描き、間違いが痛い場所に人の承認を1つ置く ・各ノードを新しいチャットで自分で演じて手で回す。1回で答えさせるより目に見えて良くならなければ、自動化しない 【結論】 ・エージェントを増やせば良くなるわけではない。5つのエージェントが自信満々で同じ間違いにたどり着くこともある ・目指すのは、待ち時間を実際に減らし、確認役と作業役を分け、間違いの代償が大きい場所に人を入れ、止めどきを知っている最小のグラフ

ソフトウェアエンジニアはAIに対してラッダイトになれる立場ではない、という記事 seangoedecke.com/software-en… ・AIに仕事を奪われると怒るソフトウェアエンジニアに対して、その資格はないと説くエッセイ ・筆者のSean Goedecke氏は、職業の土台にしてきた技能が自動化されて腹が立つのは理解できるという ・ただ、ソフトウェアエンジニアは一番文句を言ってはいけない立場だ。「剣を取る者は剣で滅びる」 ・ソフトウェアは最初から他人の仕事を自動化してきた。商用ソフトの価値は、人に頼むはずの作業を代わりにやることにある ・初期の表計算ソフトVisiCalcの開発者も、帳簿係の仕事を奪うのではと悩んでいた ・ビデオレンタル店、旅行代理店、レコード店、写植、データ入力など、多くの業種がソフトウェアに置き換えられた ・自分たちの番が来たとたん「ソフトウェア開発はかけがえのない技芸だ」と言い出すのは筋が通らない ・ラッダイトは、力織機などの登場で職を失った19世紀イギリスの織物職人たち ・AIを嫌うエンジニアには彼らが英雄に見える。だがエンジニアは職人の側ではなく、織機を作った鍛冶屋や機械工の側だ ・皮肉にもその機械工も、約50年後に未熟練の少年や労働者に置き換えられた ・機械工のストライキは暴力もなく、4か月後に資金が尽きて終わった ・偽善者と見られたことも一因で、タイムズ紙は「手織り工と同じ叫びにすぎない」と書いた ・ソフトウェア開発の本質は、退屈な作業を機械に任せ、人の労働を置き換えること。つまり人の仕事をなくすことだ ・CSSや実行時エラーに悩んでいると、パズルを解いているように感じる。だがそれは作業の手触りであって、仕事の正体ではない ・楽観的に見れば、自動化は進歩だ。医療の普及、子どもの死亡率の低下、食料の増産、宇宙開発を可能にしてきた ・今は気候変動、2008年の金融危機、SNSの悪影響、テック企業トップの右派への接近などで、技術を悪者とする見方が広がっている ・どちらが正しいかは筆者にもわからない。それでもエンジニアは、口で何と言おうと、常に技術と自動化の側で働いてきた ・技術の長い目で見た影響から目をそらし、目の前のパズルに集中したくなる気持ちはわかる ・しかし自動化の波が自分の業界に来たこの時になって、技術の進歩に反対するのはみっともない ・他人の仕事をなくしたり変えたりしてきたのが悪いと思うなら、自分の仕事が同じ目にあうのも受け入れるべきだ ・追記では、人間には不可能な仕事をするソフトもあると認め、自動化で得をしてこなかった人を責める意図はないとしている ・AIを嫌う理由はほかにもあり、自動化への反発以外の理由でAIに反対することまで否定するものではないとも補足している