Graphエンジニアリングとは？——LoopとGraphをどう使い分け、毎週回す仕事をAIの「走る地図」へ昇格させるか

家事と子育てのスキマで経営する3方よしAI共創コンサルタントの田中啓之、ひろくん（@passion_tanaka）です。

前回の記事「大きなループの中に、小さなループがある」で、私は鬼速PDCAとループエンジニアリングを「入れ子構造」で一本につなぎました。その最後に出てきたのが、複数のLoopの関係を見えるようにするGraph——いわば「見える地図」の話です。

で、記事を公開した翌日。海外のコンテンツ運用者が、まさにその続きにあたる図を投稿していたんだよね。タイトルは「A GRAPH IS A MAP OF LOOPS + CHECKPOINTS（グラフとは、ループと改札の地図）」。読んだ瞬間、あ、これは前回の記事の「次の一歩」だと思いました。

今回はこの一次情報を引用しながら、「見える地図」の先にある「走る地図」の話をします。LoopとGraphをどう使い分けるか、その判断基準まで持ち帰ってもらえたら嬉しいです。

前回のおさらい——「見える地図」まで来た

まず、前回までの話を1分で振り返ります。

Loopは、一つの仕事がAIの中で「作る→確かめる→直す」を繰り返す動きでした。記事を書かせると、AIは下書きし、素材と照らして読み直し、弱い部分を書き直し、合格ラインを超えるまで自分で周回します。

そしてLoopが増えてくると、今度は「全体がどこで止まっているのか」がわからなくなる。調査AI、執筆AI、検証AI、人間の承認待ち。この関係を見えるようにするのがGraphで、私はAGI Cockpitのタスクボードを読み取り専用のGraphとして読めるようにする実装（Phase 1）を紹介しました。

ここで一つ、正直に言っておくと。前回のGraphは「読む地図」なんです。カーナビで言えば、渋滞状況が見えるだけの画面。地図を見て、ハンドルを握るのはまだ人間とそれぞれのAIでした。

7月18日（日本時間）にPeter Steinbergerさんが投げた「まだLoopの話なのか、もうGraphへ移ったのか？」という問いには、実はもう半分、答えが残っていました。地図は、読むだけのものなのか。走らせることはできないのか。

Graphエンジニアリングとは——「グラフとは、ループと改札の地図」

その答えをくれたのが、海外でコンテンツ制作の代理店を運営するShannさん（@shannholmberg・2026年7月20日の投稿）です。彼はSEO記事を書くAIエージェントを例に、こう説明しています（以下、引用は私の和訳）。

Loopでは、人間が決めるのはゴールと素材と合格ラインだけ。そこまでの道順は毎回AIが選びます。一方Graphでは、人間が先に手順と分岐を描く。同じSEO記事でも、こういう地図になります。

ポイントは、途中に置かれた「？」の関所です。Shannさんはこれをcheckpoint（チェックポイント）と呼びます。私は「改札」と訳したい。改札は結果を読んで、仕事の行き先を振り分けます。合格なら前へ、不合格なら前の部屋へ戻す。

そして彼の定義が、そのままこの記事の核心です。

つまりGraphはLoopの「乗り換え先」じゃない。小さなLoopを部屋ごとに閉じ込めて、部屋の間に改札を置いた地図なんです。前回の記事で書いた入れ子構造が、そのまま地図になった形だと思ってもらえたら正確です。

そして彼はもう一つ、大事なことを言っています。「地図が完成したら、次の対象を流し込むだけで、パイプライン全体がもう一度走る」。地図は使い捨てじゃなく、資産になるということです。

そして、この「部屋（Loop）と改札を設計して、AIが走れる地図に組み上げる技術」には、海外で呼び名がつき始めています。「Graphエンジニアリング（graph engineering）」です。Steinbergerさんの問いかけの直後、2026年7月中旬から広がり始めた言葉で、AI研究者のCarlos E. Perezさんは「より良いループではなく、ループのグラフ——互いに見張り、材料を渡し、制約し、補正し合う改善サイクルのネットワークが次の答えだ」と整理しています（筆者和訳・要約）。Loopの回し方——目的・検証・止まり方を設計するのがループエンジニアリングなら、Graphエンジニアリングは、そのLoopたちをどの部屋に置き、どの改札で結び、どこを人間に残すかを設計する仕事。つまり一皿の作り方の設計から、厨房のライン設計へ、一段外側に出た設計技術です。

LoopとGraphをどう使い分ける？——基準は「その仕事、何回やる？」

じゃあ、どの仕事をLoopで回して、どの仕事をGraphに昇格させるのか。Shannさんの基準はシンプルでした。

これ、料理に例えるとすごく腑に落ちるんだよね。

Loopは日替わりの一皿です。今日だけのお客さんに、今日だけの食材で作る。レシピを固定する意味はあまりなくて、腕のいい料理人に「この味まで持っていって」と任せて、味見と修正を繰り返してもらうのが速い。

Graphは常設メニューの調理ラインです。毎週何十皿も出す看板メニューなら、仕込み→調理→味見→盛り付け→提供の手順と検品場を一度きちんと設計する。設計は面倒だけど、翌週からは食材を流し込むだけでラインが動く。

そこで今回、うちでは「3回ルール」を目安に決めました。同じ種類の依頼をAIに3回したら、それはもう日替わりじゃなくて常設メニュー。Loopのまま毎回口頭で頼むのをやめて、地図に昇格させるサインと見なします。後で紹介するArchiveさんの記事にも「同じタスクが3回目に来たときに作る3つのスキルは、先回りで作った50個に勝る」という同じ発想の経験則が出てきて、これをGraph昇格の物差しに借りた形です。

改札の設計が、品質の生命線

ここが今回いちばん伝えたいところです。走るGraphの品質は、部屋の性能じゃなく改札の設計で決まります。

改札に置くものは、突き詰めると「合格基準を言葉にしたもの」です。あいまいな「いい感じにして」は改札になりません。「タグは設定されているか」「リンクは全部生きているか」「文字数は基準を超えているか」「この表現はブランドの価値観に反していないか」。答えがYES/NOで出る問いだけが、仕事を振り分けられます。

私の運用では、改札は性質ごとに3段に分けています。

1. 機械の改札——スクリプトで機械的に検査できるもの。リンク切れ、画像の枚数、文字数、HTMLの構造。ここは人間もAIも通さず、プログラムに任せる
2. AIの改札——文章のトーン、価値観との整合、読者にとっての分かりやすさ。私の判断基準を学んだ分身AIが一次判定する
3. 人間の改札——外に出る最後の一枚。公開、配信、課金。ここだけは今も私が通す

逆に言うと、改札が甘い地図は怖いんです。Loopの失敗は一皿の失敗で済むけど、間違った地図は、間違いを毎週量産する機械になる。地図を描く手間より、改札を吟味する手間のほうにこそ時間をかける価値があります。

前回の記事のFAQで「Graphを作れば複数のAIが自動でうまく動きますか？」に「いいえ」と答えました。あの答えは今回も変わりません。走るGraphが成立するのは、各部屋のLoopに目的・証拠・停止条件があり、部屋の間に本物の改札があるときだけです。

この形には名前がある——ステートマシン

「部屋（状態）があって、改札が結果を読んで行き先を変える」。この形には、ソフトウェアの世界で昔からの名前があります。ステートマシン（状態機械）です。

Shannさんも書いています。「n8nでワークフローを組んだことがあるなら、あなたはもう地図を描いたことがある。ノードをつなぎ、条件で分岐させ、クリアするまで繰り返すステップを置く——その絵がグラフだ。エージェントのグラフも同じ形で、ノードの中身が単発のAPI呼び出しからAIエージェントに変わっただけ」。

技術的な裏付けも前回と同じ整理で大丈夫。OpenAI Agents SDKのRunnerが管理するのは、モデル呼び出し・ツール実行・再実行・終了というエージェントの実行ループ。一方、LangGraphのStateGraphが扱うのは状態を共有するノードとエッジ、つまり地図側です。LangGraphにはcheckpointer（実行状態の保存係）が用意されていて、途中で止めて、人間が確認してから再開する、という運転も設計できます。

難しく聞こえるかもしれないけど、実態はレストランの厨房に貼ってある「調理工程表」と同じです。名前を知る価値は、検索できるようになること。「agent graph」「state machine」で調べると、世界中の実装例に一気につながります。

AIの「走る地図」は、私の厨房でもう毎日走っている

ここからは一次情報です。ぶっちゃけ、私はこの図に出会う前から、知らないうちに「走るGraph」を描いていました。

うちのAI氣道では、過去のLIVE配信記事をリライトするパイプラインが走っています。最初に引いた地図は、こういう形でした。

それぞれの部屋の中では、AIが小さなLoopを回しています。リライトの部屋では書いて読み直して直しているし、検証の部屋では基準に照らして差し戻している。でも部屋の順番と改札は固定です。最初のころは毎朝数本ずつ流して、私が朝起きると、改札を全部通った候補だけがプレビューで届いていました。

そして、ここからが地図の面白いところで。合格が積み上がると、地図は育つんです。このラインは増強されて、多いときは約740本の過去記事を相手に、昼も夜も2時間おきに1波15本・1日12波という規模で走るまでになりました。改札はむしろ増えていて（話者の同定、捏造の検出、私の声の基準を守る契約、機械のlint）、そのかわり人間の改札は「公開するかどうか」の一枚に集約。ラインは公開の手前で必ず止まる設計で、朝のChatworkには夜の実績サマリが1通届くだけです。そして流す量を絞るのも増やすのも、地図を持っている人間側の運転——止めるという判断も、改札の一つです。新しい朝LIVEを記事にするラインは、今も毎朝走っています。前回の記事で書いた「人間は地図の外側へ上がる」が、ラインの上で実際に起きた形です。

7月20日に公開した講座動画も同じでした。ブログ記事→対話台本→スライド→音声→アバター→動画合成→機械検証14項目→YouTube限定公開→私の味見→一般公開。こうして部屋と改札を仕事が流れて、最後の一枚だけ私が通す。

面白いのは、私はこれを「Graphを作ろう」と思って作ったわけじゃないことです。毎週繰り返す仕事から、自然に地図が生えてきた。Shannさんの「Graphが元を取るのは毎週繰り返す仕事」という基準を、逆側から実証していた形になります。

だからもし、あなたが毎週同じ依頼をAIにしているなら。それはもう地図の材料が揃っているということです。

ハーネスは床——もう一つの一次情報「厨房とレシピ」

もう一本、今回引用したい投稿があります。Xで累計260万回以上表示されている（2026年8月2日時点）Archiveさん（@ArchiveExplorer）の長文記事（2026年6月28日）。LoopとGraphの下にある、もう一つの層の話です。

ハーネスとは、AIが働く実行環境のこと。道具、権限、ルール、記憶——厨房で言えば、包丁とコンロと衛生ルールとレシピ棚です。この記事が刺さるのは、失敗の診断を層で分けているところなんだよね。トークンの浪費や権限エラーは厨房（ハーネス）の問題。何周しても収束しないLoopや、ゴミを合格させる検証はレシピ（Loop）の問題。層の名前が付くと、直す場所を間違えなくなる。

裏付けになる研究も確認しました。Microsoft Dynamics 365の経費処理をAIエージェントに任せた50タスクの実験（arXiv:2606.10209）では、会話履歴を全部持たせた場合のタスク完了率は71.0%。ところが直近のやり取りだけ残して要約を添えると91.6%まで上がり、トークン消費は約63%減りました（約148万→約55万トークン）。文脈は多いほど良いのではなく、仕込み（整理）の質が結果を分ける——厨房の整頓がレシピの再現性を決める、ということです。

Archiveさんの締めの一文が、今回の3層をきれいにまとめてくれます。

前回の料理の対応表に、今回の話を足すとこうなります。

毎週回す仕事をどっちで回す？——今日から使う判定表

最後に、明日から使える形に落とします。あなたがAIに頼んでいる仕事を一つ思い浮かべて、上から順に当ててみてください。

そして、最初の地図は紙で十分です。いきなりn8nやプログラミングじゃなくていい。手順を箇条書きにして、間に「ここで何をチェックするか」を1行ずつ書く。それがもう地図の下書きです。私のおすすめは、最初の改札を「公開前チェックリスト1枚」にすること。機械に渡すのはその後で間に合います。

正直にリスクも書いておきます。Graphには初期工事のコストがあるし、間違った地図は間違いを毎週量産します。それから、地図は例外に弱い。想定外のケースが来たら無理に流さず、「例外は人間へ上げる」という改札を最初から一つ入れておいてください。ここをサボると、Loopの静かな失敗と同じ事故が、今度はライン全体で起きます。

まとめ

今回の話を一枚に畳むと、こうなります。

• Graphエンジニアリングとは、Loopと改札を「走る地図」に組み上げてAIに走らせる設計技術。ループエンジニアリングの一段外側の層
• LoopとGraphの違いは「道順を決めるのが誰か」。Loopは着地点だけ決めてAIに道を探させ、Graphは人間が地図を描いてAIに走らせる
• グラフとは、ループと改札の地図。部屋の中でLoopが回り、改札が結果を読んで仕事を運ぶ。前回の入れ子構造が、そのまま地図になった形
• 使い分けの基準は「その仕事、何回やる？」。一回きりはLoop、毎週回す仕事はGraphへ。3回目の依頼が昇格のサイン
• 品質を決めるのは改札の設計。機械→AI→人間の3段に分け、外に出る最後の一枚だけは人間に残す
• ハーネスは床。床→レシピ（Loop）→地図（Graph)の順に整えると、失敗の診断も直す場所も迷わなくなる

ループの次に設計するのは、そのループが走る地図だ——Shannさんの投稿はそう締められていました。私の答えはもう決まっていて、毎週回す仕事を、一枚ずつ「走る地図」に昇格させています。あなたの厨房の常設メニュー、どれから地図にしますか？

関連記事・CTA

• Claude Fable 5時代の「ループエンジニアリング」入門——AIに毎回お願いする働き方は、もう古い？
• ループエンジニアリングの落とし穴——AIが静かに失敗し課金だけ続けた話と、安全な止め方
• 大きなループの中に、小さなループがある——鬼速PDCAとループエンジニアリングをつなぐ構造

AIを一人で抱え込まず、実践例を持ち寄りながら試したい方は、GPTs研究会にも参加してみてください。

参考リンク・資料

• Shann（@shannholmberg）, what’s the difference between a loop and a graph? (marketing edition)（2026年7月20日・本文中の引用は筆者による和訳）
• Archive（@ArchiveExplorer）, Loop and Harness engineering: 7 files, 5 steps. Every config inside（2026年6月28日・X長文記事）
• Peter Steinberger, Are we still talking loops or did we shift to graphs yet?（2026年7月18日 日本時間・7月17日 米国時間）
• Carlos E. Perez, From Loop Engineering to Graph Engineering?（Intuition Machine, Medium, 2026年7月19日）
• Lodha et al., Less Context, Better Agents: Efficient Context Engineering for Long-Horizon Tool-Using LLM Agents（arXiv:2606.10209, 2026年6月）
• OpenAI, Running agents — OpenAI Agents SDK
• LangChain, Use the graph API — LangGraph

※この記事は、外部一次資料の照合と自社パイプラインの実装記録をもとにAI氣道のコンテンツエンジンで構成し、出典照合と品質チェックを行って公開しています。X投稿の引用はすべて筆者による和訳で、原文は各リンク先を参照してください。