2026年7月、AI駆動開発は複数のAIを組んで同時に走らせる段階に入りました。この組み方がグラフエンジニアリングです。
ループまでの自動実行は、いわば1体のAIを安全に走らせる工夫でした。速くするには複数を同時に走らせるしかありませんが、そうすると「どれが終わったら次を動かすか」を人が捌き続けることになります。夜中は手が止まり、出来上がった成果物がどの判断を経てきたのかも、後から追えなくなる。ここが限界でした。
グラフは、この捌きを図面に写したものです。
図面の通りにしか動かないので、何本を同時に走らせても実行順は崩れず、人がいない時間も止まりません。そして「この仕様は誰がOKしたのか」に、後から答えられます。上のGIFは、この考え方を工程の承認と検収のあいだに収めた、受託開発向けの実行図です。フェーズごとに、同じ図が前へ進みます。
詳しくは以下記事で。
AI活用の重心は、数年かけて移り変わってきました。順に並べると、いま自分がどこにいるかが分かります。
| 段階 | 何を工夫するか | 一言でいうと |
|---|---|---|
| プロンプト | AIへの聞き方 | 聞き方を磨けば良い答えが返る |
| コンテキスト | AIに渡す資料 | 何を見せるかで答えが決まる |
| ハーネス | 安全装置 | 触ってよい範囲を機械的に制限する |
| ループ | 自動実行 | 人が見ていなくても定型作業が回る |
| グラフ | 分担のさせ方 | 役割を分けたAIのチームに、仕事を割り振って同時に走らせる |
2026年7月に広まった「グラフエンジニアリング」は、この最後の段です。機能Aの設計と機能Bの設計を同時に書かせる、書いたものを別のAIに検査させる、夜のあいだに定型作業を回しておく。ここまでは、流れとして自然な進化です。
問題は、受託開発でこれをやったときに起きます。一つずつ指示していた頃は、指示した人が決めた人でした。分担させて同時に走らせると、速くはなりますが、成果物が増えても判断の記録は増えません。気づくと、どの記述がどの判断を経てきたのかが、誰にも分からなくなっています。
受託開発では、これが最後に一度に返ってきます。検収の場で問われるのは、動くかどうかではありません。
この仕様は誰がOKしたのか。このテストは何を根拠に合格としたのか。
答えられなければ、動いていても差し戻されます。速さのために曖昧にした分は、必ず後半で払うことになります。
だから、AIをどこまで使うかより先に決めるのは、AIに任せる範囲と、人が決める範囲の線です。そして受託開発には、その線がもともと引いてあります。工程の承認と、検収です。
以下は、その考え方を開発標準として整理したものです。受託開発の現場でClaude Codeを使うためのサブエージェント・スキル・運用標準の一式を「Claude Code プロジェクトパック」としてMIT Licenseで公開しています。設計の土台にある考え方はClaude Code プロジェクトパック公開に書きました。
GitHubリポジトリ: https://github.com/CT-masato-hino/claude-code-project-pack
公開は今月初めで、そこから v3.1.0 に更新しました。入れたのはグラフの軸です。
新しい機構を発明した更新ではありません。既存の統制に適用範囲と判定基準を足しただけです。文書の置き場所・基準の番号・エージェント名・スキル名は変えていないので、導入済みの案件はそのまま動きます。
抽象的な整理ではなく、手元の作業が変わった点を挙げます。
| 変わったこと | 以前 | v3.1.0 以降 |
|---|---|---|
| 機能IDと設計書・テストの突き合わせ、既存モックからの機能一覧の起こし、納品前の一括点検 | 一件ずつ順に頼むしかなく、件数が増えると時間がそのまま伸びた | 開始条件のチェックリストを満たせば並列に投げられる。標準レシピ3本があるので、毎回の設計から始めなくてよい |
| 並列に投げてよいかの判断 | 案件ごとに議論していた | 「次の工程は前の出力を実際に読むか」から始まる適用基準と、7項目の開始条件で事前に決まる |
| 定期実行の運用 | 「自動で回してよいか」を都度判断していた | 目的関数（照合型か改善型か）を申告する欄ができ、改善型が完成定義に紛れ込む事故を止められる |
| 過去の検討 | 採らなかった判断が残らず、同じ議論を繰り返すか、後から「対応漏れ」として実装されていた | 判断・理由・再検討の条件の三点セットで記録される |
派手な機能追加はありません。判断に要る材料が増えて、毎回ゼロから決めなくてよくなった、という種類の更新です。
外部の方法論はIssueとして起票し、既存の統制と一項目ずつ突き合わせてから還元する手順にしています。v3.0.0 は Issue #38「外部方法論『Graph Engineering』の精査結果からの還元」の成果物です。精査の結論は次のとおりでした。
世間で「Graph Engineering」と呼ばれる方法論の中核規律 ― 検証ノードの独立文脈、目標の形骸化の検知、動かないアンカー、並列衝突対策 ― は、本パックがQ-11（生成と検証の分離）・品質ループの停止判断・「数値なしの合否宣言は無効」・ERD独占管轄／採番前の台帳突合として既に持っていたものである。
新しかったのは原則ではなく、それを並列の幅に適用するときのルールでした。
取り込む前に整理が要りました。「Graph Engineering（グラフエンジニアリング）」は2026年7月に英語圏のSNSで急速に広まった語ですが、二通りの意味で使われているためです。どちらを採るのかを決めないと、統制の当てどころが定まりません。順に見ていきます。
AI駆動開発の重心は、プロンプト → コンテキスト → ハーネス → ループ と移ってきました。グラフはその次の段として置かれています。つまりループの発展形であり、エージェントの実行そのものをノードとエッジで組み立てる話です。
この見方を実装に引き付けて書いた記事に、AI Builder Club の「Graph Engineering with Claude Code」があります。専用のフレームワークは要らない ― サブエージェントがノード、オーケストレーターの委譲判断がエッジ、返された結果が状態の流れにあたり、Claude Code が既にその機構を備えている、という整理です。新しい機構ではなく既存の道具の設計パターンだという結論は、本稿の判断とも重なります。
同じ語が、次のような内容にも使われています。
こちらはナレッジグラフやグラフDBの文脈にある話で、データモデルをどう構成するかという問題です。実行の制御と、データモデルの構成。同じ「グラフ」という語が、この二つを指しています。
どちらも実務的な主題です。特に「探索をモデルに任せない」は、コストと再現性の両面で有効な指摘だと考えています。読むときにどちらの意味で使われているかを確かめておくと、話が通りやすくなります。
出所についても一点触れておきます。最も拡散した投稿は「Anthropicのエンジニアが社内のプレイブックを流出させた」という文言とともに、研究ノート体裁の一枚図を添えて共有されました。その図の下部には、独自に編集したものであり Anthropic とは無関係である旨と、"Conceptual mockup / fictional research note" という注記が入っています。つまり、流出文書ではなく、公開情報をもとに編集された架空の研究ノートです。
中身に価値がないという話ではありません。ここで指摘したいのは、その扱われ方が、受託開発にAIを入れるときの中心的な失敗と同じ形をしているという点です。
権威の見た目だけで方法論を採用することと、AIの成果物を自己レビューで通すことは、構造として同じです。どちらも、出所と根拠の検証を省いて結論だけを受け取っています。生成と検証を分けることをAIには課しておきながら、方法論を採るときには出所を確かめない、という状態には一貫性がありません。
この二つを分けたうえで、それぞれをパックのどこに当てるかを決めました。次節がその判断です。
パックでは v3.1.0 で、この二つを別の軸として定義しました。そのうえで、実行の側は部分的に採用し、データの側は名前を与えるにとどめるという判断をしています。
この二つは、AI駆動開発の重心の変遷を捉えた4層モデル（プロンプト → コンテキスト → ハーネス → ループ）の中での位置づけが違います。実行のグラフはループ層の上に乗る実行の幅であり、下の層を整備しないまま手を出さないという原則がそのまま適用されます。知識のグラフは層ではなく、全層を貫く土台です。
速くなるほど、成果物から「誰が通したか」へ戻る線は細くなる。
受託開発では、ここが曖昧なまま進んだ分が検収で戻ってくる。境界を後から引き直すのは高くつく。
順序を入れ替えることはできません。突き合わせる正本がないままファンアウトすると、エージェントが互いの主張を承認し合うだけになります。ノードを増やしても真実は増えません。
このパックの場合、知識のグラフは v1.0 から動いていました。機能IDから検収までの連結、まだ決まっていないことの一覧、どの版を誰が承認したかの記録、次のセッションへの持ち越しがそれにあたり、名前がついていなかっただけです。実行のグラフを v3.0.0 で後から安全に足せたのは、突き合わせ先が先に存在していたからでした。
実行の側を「部分的に」と書いたのは、適用範囲を絞っているからです。人間の判断ゲート（工程承認・リスク受容・検収）は常に並列の外に置き、逐次依存のある仕事・探索的な作業・小さなタスクには適用しません。エージェントが自分でプランを書き替える形（動的プランニング）も採っていません。採ったのは、依存のない同型タスクを並列に投げて独立に検証する部分だけです。
ワークフロー実行標準では、開始条件をチェックリストにしています。ハーネスが揃っていること、書き込みを伴うタスクは作業場所を分離すること、マージ計画と矛盾時の裁定者を事前に決めること、検証エージェントが実行側の文脈を引き継がないこと、初回は件数上限つきで走らせること、停止手段と上限があること、結果を正本に落とすこと。一つでも欠けたら開始しない、という運用です。
このうち最後の一項目は見落とされやすいものです。並列実行の結果がスクリプトの変数の中にしか存在しない状態は、成果物としては何も残っていないのと同じで、揮発します。
ここから先はデータの側の話です。実行の側とは別の軸になります。
知識のグラフに名前をつけたとき、対応表を書いてみて分かったことがあります。パックが持っていた仕組みは、実装としてはそのまま知識のグラフでした。
検収で問われるのは、動くかどうかではなく、誰が何を担保したか。
この仕様は誰が決めたのか、このテストは何を根拠に合格としたのか。答えられなければ、動いていても差し戻される。
冒頭に挙げた六段階のループを、受託開発の工程に置き換えると次のようになります。
| 外の議論での段階 | 受託開発での対応 | 担い手 |
|---|---|---|
| 抽出 | 現行資料・議事録からの機能一覧と受入基準の起案 | AIが起案し、人が承認する |
| 名寄せ | 用語の統一、機能IDの採番、重複機能の統合 | 採番の権限は特定の担当に閉じる |
| 組み立て | 設計書項番・テスト番号への連結 | 成果物を作る過程で自然に生成される |
| 検証 | トレーサビリティ断絶の機械検出、生成と検証の分離 | 実装したエージェント以外が行う |
| 永続 | docs正本主義、引き継ぎコンテキスト、成果物台帳 | gitのPRが調停役になる |
| 反復 | 週次のQCDレポート、工程ゲート | leaderが判定し、人間が承認する |
三列目に注目すると、受託開発でこれらを担っているのは、多くの場合AIではなく人間の運用そのものです。ここに、この記事で最も伝えたい点があります。
受託開発は、知識のグラフの構築費を先に払っている。
機能IDを振り、受入基準に紐づけ、設計書項番とテスト番号に連結した時点で、グラフの構築作業は終わっています。しかもそれは「グラフを作るため」にやったことではありません。検収に耐えるトレーサビリティが業務上必要だから作ったのであって、グラフは副産物として手に入っています。
RAG文脈のグラフ構築が難しいのは、この前払いがない文書が対象だからです。誰も構造化していないPDFやWikiから、機械が推測で実体と関係を取り出す。抽出の精度も名寄せの精度も保証がなく、検証工程が重くなるのは当然の帰結です。
受託開発の成果物は、その逆の位置にあります。ID体系が先にあり、承認記録がついていて、断絶があれば機械的に検出できる。だからこのパックはグラフDBを導入していません。grepと同梱の点検ツールで足りています。
ただし、限界は正直に書いておきます。
三つ目は、AI導入の効果が組織によって大きく違う理由でもあります。トレーサビリティを形式的に整えているだけの組織では、前払いの中身が空です。その状態で知識のグラフを名乗っても、AIが引くのは空の索引になります。
外の議論のうち、最も実務的なのは「探索をモデルに任せない」という指摘です。インデックスだけで候補を絞り、開くのは1〜2ファイルにして、モデルは考える仕事に使う。個人のノート環境ではこれが直接効きます。
受託開発でこれに対応する作業は、しかし索引の整備ではありません。どれが正しい文書か（正本）を一つに決めることです。
同じ仕様が、要件定義書と基本設計書と課題管理表とチャットの決定事項に、少しずつ違う内容で四通り書かれている。この状態でどれだけ精緻な索引を作っても、引いた先が矛盾しているのでは意味がありません。索引は正本の上にしか成立しません。
外に置くのは、合意と責任を伴う判断。内側は経路が増えても構わない。
経路が増えても、境界をまたがなければ責任の所在は動かない。迷ったら止めて人に上げる。
個人のノートと業務システムの決定的な差はここにあります。業務システムの正本は複数の組織にまたがって存在し、それぞれに承認記録がついています。「どれが正しいか」は技術的な問いではなく、誰が承認したかという契約上の問いです。
パックでは、docs配下の正本主義と、引き継ぎコンテキストがこれを担っています。本体は最新の状態を保持する一枚のファイルで、履歴はアーカイブ側に分かれています。次のセッションが白紙から始めないための持ち越し先です。
「記憶させるのではなく引かせる」という主張自体は、受託開発では新しいものではありません。属人的な記憶に頼らず正本を引くのは、もともとの作法です。AIが入って変わったのは、正本が整っていない組織のコストが即座に、しかも目に見える形で表面化するようになったことのほうだと考えています。
人間なら、四通りの記述を前にして「たぶんこれが最新だろう」と判断し、必要なら書いた人に確認します。AIは確認に来ずに、もっともらしいほうを選んで作り切ります。まだ決まっていないことに番号をつけ、一覧で追う設計にしているのは、この差を埋めるためです。
外の議論で繰り返し語られる絵のひとつが、夜のうちにエージェントを自動で回し、朝には昨日より良くなっている、というものです。
受託開発でこれを実施するとき、危険なのはループそのものではありません。目的関数です。v3.1.0では、ループを二種類に分けて定義しました。
完成の条件につないでよいのは、合否が出て終わるほうだけ。
終わらない仕事を完成の条件に混ぜると、品質は上がっても、いつ終わったのかを誰も言えなくなる。
原則はひとつです。
改善型ループは持ってよい。ただし完成定義（工程完了条件・検収条件）に接続してはいけない。
改善型が危険なのは、成果物に書き戻す場合だけではありません。改善余地を可視化し続けると、その一覧自体が要求として振る舞い始めます。
したがって「観測だけなら安全」は成立しません。観測・提案・自律のどの形態にも、照合型と改善型の両方がありえます。脆弱性検知は照合型ですがKPI追跡は改善型、仕様差分の修正提案は照合型ですがリファクタリング提案は改善型です。分類の軸は自律度ではなく目的関数のほうにあります。
この区別も、実は既存の装置がすでに実装していたものでした。品質ループの停止基準（残ったShould・Nitsを工程完了の条件にしない）は、改善型の出力を完成定義から切り離す宣言です。自己増殖の検知（起票数が解決数を上回る、同一課題に「完全解決」が二度出る）は、改善型ループの暴走検知にあたります。数値を伴わない合否宣言を無効とするルールは、改善の主張に動かないアンカーを要求するものです。
改善型の成果を捨てるわけではありません。行き先を契約に合わせて分けます。保守契約があるなら次期の見積り対象へ、なければ次の案件の提案材料へ、汎用性があるなら社内の規約とチェックリストへ。請負契約では完成定義から完全に切り離し、準委任では余地が広くなります。
品質基準を落として得た工期短縮を成果として計上しない、という統制と同型のものだと考えています。いずれも、価値の計上先を間違えないための仕組みです。
v3.1.0では、テーラリングガイドに「意図的に採用していないもの」の節を新設しました。削ってはいけないものと、足すことが多いものは既に書いてありましたが、検討したうえで採らなかったものの記録がありませんでした。
記録がないと二つの事故が起こります。後から誰かが「対応漏れ」として実装してしまうか、逆に、検討済みであること自体が失われて同じ議論を繰り返すかです。日本の受託開発では、標準に載っていない項目は「考えていない」と読まれがちで、この記録は対外的な説明にも使えます。
全項目を、判断・理由・再検討の条件の三点セットで書いています。理由だけでは将来の判断材料になりません。
| 検討したもの | 判断 | 主な理由と、再検討の条件 |
|---|---|---|
| サーバ型グラフDB（Neo4j等） | 不採用 | 統制対象が増えるのに納品物にならない。Neo4j Community Edition のGPLv3は納品物への組み込み時に法務確認が要る。クラウド版は顧客の設計情報の所在が変わる。最大の問題は二つ目の正本ができること。再検討はグラフ自体が納品物になる案件、共有グラフへの同時書き戻し設計、数千ノード規模の対話的探索が必要になったとき |
| 派生インデックス（docsから生成するSQLite） | 現時点では不要 | 多段の追跡はプロンプト層で成立している。入れる理由は速度でもコスト削減でもなく、完全性の証明と再現性の二つだけ。発動条件は、辿った結果をゲート判定や検収の根拠として人間に提出する必要が出たとき |
| 動的プランニング（自力でのリルート） | 不採用 | 「勝手に仮定を作らない」「テーブル変更が必要になったら停止して報告」と正面衝突する。工程・ゲート・WBSという人間側の計画レイヤーが既に計画を担っている。再検討は人間の承認ゲートの外側に限った部分適用なら余地がある |
グラフDBの項目は、外の議論の核心と最も距離のある判断です。しかし理由は技術的な優劣ではありません。二つ目の正本ができることが、docs正本主義と正面から衝突するためです。
派生インデックスの項目では、入れる理由を明確にしておくことに意味がありました。速い・安いという理由で導入すると、期待した効果が出ずに統制対象だけが残ります。得られるのは、AIの辿りが「もう十分」で止まるために証明できない取りこぼしゼロの担保と、別セッションで経路が変わらないという再現性の二つです。どちらも、成果物として人間に提出する段になって初めて必要になります。導入する場合も正本にはせず、CIで生成して配布し、壊れたら再生成する扱いにします。
採らないと決めたものを案件側で変える場合も、同じ三点セットでテーラリング記録に残す運用にしています。
AI駆動開発の方法論は、今後も数ヶ月単位で新しい語彙とともに流通します。実装が追いつく速度より、語彙が入れ替わる速度のほうが速い状態が当面続くはずです。
その中で、v3.0.0とv3.1.0の作業を通して確かめられたことが三つあります。
第一に、外から来た方法論の中核規律は、多くの場合すでに自社の統制の中にあります。名前が違うだけで、生成と検証の分離、動かないアンカー、目標の形骸化の検知は、プロジェクトマネジメントが昔から持っていたものです。新しいのは原則ではなく適用範囲のほうで、今回であれば並列の幅がそれにあたりました。
第二に、すでに動いているものに名前がついていないと、外の議論と読み合わせられません。知識のグラフはv1.0から動いていましたが、名前がなかったために、外部の議論を読んだ人から「このパックにはグラフがない」と見えていました。名前をつけることは、機能の追加ではなく接続の回復です。
第三に、採らない判断のほうが、採る判断より記録の価値が高いことです。採ったものはコードとドキュメントに残りますが、採らなかったものは何も残しません。
導入を検討する立場の方には、外部の方法論を自社標準に取り込むかどうかを判断する際に、次の三点が使えると思います。
その規律は、自社の既存の統制のどれに対応するか。名前が違うだけではないか。
出所と根拠は検証したか。権威の見た目だけで採っていないか。
採らないと決めた場合、その理由と再検討の条件は記録に残るか。
パックの前提にある工程側の考え方 ― ウォーターフォールの各工程で誰が何を承認し、コンテキストとハーネスで生成をどう統制するか ― はウォーターフォールでAI駆動開発を回すに、社内承認を通すための統制の配置はAI駆動開発の最初のハードルは社内承認に整理しています。
テーラリングと組織への定着は、ドキュメントだけでは進まない領域です。Chapter Techでは、エンタープライズ企業向けの導入・統制設計をエンタープライズDX & FDE支援サービスで、開発プロセスへの組み込みから効果測定までの定着支援をAI Delivery Scope+で提供しています。導入前の相談はお問い合わせからどうぞ。
v1.x から導入済みの案件については、docs配置に後方互換のない変更が入っています。移行手順はリポジトリの初期化スキルのフェーズ0にまとめてあります。