2026年7月、AI駆動開発の界隈で「Graph Engineering（グラフエンジニアリング）」という語が英語圏から広まりました。コンテキストウィンドウは記憶ではないため、事実と関係を知識のグラフとして外に置き、エージェントにそこから引かせる、という主張です。そこで挙がる抽出・名寄せ・組み立て・検証・永続の手順を受託開発の工程に置き換えると、機能IDを振り、受入基準に紐づけ、設計書項番とテスト番号へ連結していく作業と重なります。グラフを作るためではなく、検収のために先に作ってきたものです。本コラムでは、この対応関係と、OSS公開している「Claude Code プロジェクトパック」v3.1.0 で何を採り、何を採らなかったのかを書きます。
2026年7月、英語圏のSNSで同じ主張が繰り返し共有されました。「Graph Engineering（グラフエンジニアリング）」と呼ばれています。要約すると次のような内容です。
整理としては妥当です。特に最後の「探索をモデルに任せない」は、コストと再現性の両面で実務的な指摘だと考えています。
ただ、この議論の広がり方には触れておく必要があります。最も拡散した投稿は「Anthropicのエンジニアが社内のプレイブックを流出させた」という文言とともに、研究ノート体裁の一枚図を添えて共有されました。その図の下部には、独自に編集したものであり Anthropic とは無関係である旨と、"Conceptual mockup / fictional research note" という注記が入っています。つまり、流出文書ではなく、公開情報をもとに編集された架空の研究ノートです。
中身に価値がないという話ではありません。ここで指摘したいのは、その扱われ方が、受託開発にAIを入れるときの中心的な失敗と同じ形をしているという点です。
権威の見た目だけで方法論を採用することと、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.0.0 は既存の統制を並列の幅に適用するルールであり、v3.1.0 に至っては、すでに動いているものに名前と判定基準を与えただけです。正本のパス・基準ID・エージェント名・スキル名は変えていません。
外部の方法論はIssueとして起票し、既存の統制と一項目ずつ突き合わせてから還元する手順にしています。v3.0.0 は Issue #38「外部方法論『Graph Engineering』の精査結果からの還元」の成果物です。精査の結論は次のとおりでした。
世間で「Graph Engineering」と呼ばれる方法論の中核規律 ― 検証ノードの独立文脈、目標の形骸化の検知、動かないアンカー、並列衝突対策 ― は、本パックがQ-11（生成と検証の分離）・品質ループの停止判断・「数値なしの合否宣言は無効」・ERD独占管轄／採番前の台帳突合として既に持っていたものである。
新しかったのは原則ではなく、それを並列の幅に適用するときのルールでした。
外の議論を読みにくくしている最大の理由は、「グラフ」という語が二つの異なる対象に使われている点です。パックでは v3.1.0 でこれを二軸に分けました。
この二つは、AI駆動開発の重心の変遷を捉えた4層モデル（プロンプト → コンテキスト → ハーネス → ループ）の中での位置づけが違います。実行のグラフはループ層の上に乗る実行の幅であり、下の層を整備しないまま手を出さないという原則がそのまま適用されます。知識のグラフは層ではなく、全層を貫く土台です。
上ほど新しい層。下の層を整備しないまま、上の層に手を出さない。実行のグラフはループ層の上に乗る幅にあたり、知識のグラフは層ではなく全層が参照する土台になる。
順序は入れ替えられない。知識のグラフが先で、実行のグラフは後から安全に足せる。
順序を入れ替えることはできません。突き合わせる正本がないままファンアウトすると、エージェントが互いの主張を承認し合うだけになります。ノードを増やしても真実は増えません。
このパックの場合、知識のグラフは v1.0 から動いていました。トレーサビリティの背骨、仮定台帳、成果物台帳、引き継ぎコンテキストがそれにあたり、名前がついていなかっただけです。実行のグラフを v3.0.0 で後から安全に足せたのは、突き合わせ先が先に存在していたからでした。
ワークフロー実行標準では、開始条件をチェックリストにしています。ハーネスが揃っていること、書き込みを伴うタスクは作業場所を分離すること、マージ計画と矛盾時の裁定者を事前に決めること、検証エージェントが実行側の文脈を引き継がないこと、初回は件数上限つきで走らせること、停止手段と上限があること、結果を正本に落とすこと。一つでも欠けたら開始しない、という運用です。
このうち最後の一項目は見落とされやすいものです。並列実行の結果がスクリプトの変数の中にしか存在しない状態は、成果物としては何も残っていないのと同じで、揮発します。
知識のグラフに名前をつけたとき、対応表を書いてみて分かったことがあります。パックが持っていた仕組みは、実装としてはそのまま知識のグラフでした。
機能ID→受入基準→設計書項番→テスト番号という検収のためのトレーサビリティが、そのままノードとエッジになる。
冒頭に挙げた六段階のループを、受託開発の工程に置き換えると次のようになります。
| 外の議論での段階 | 受託開発での対応 | 担い手 |
|---|---|---|
| 抽出 | 現行資料・議事録からの機能一覧と受入基準の起案 | AIが起案し、人が承認する |
| 名寄せ | 用語の統一、機能IDの採番、重複機能の統合 | 採番の権限は特定の担当に閉じる |
| 組み立て | 設計書項番・テスト番号への連結 | 成果物を作る過程で自然に生成される |
| 検証 | トレーサビリティ断絶の機械検出、生成と検証の分離 | 実装したエージェント以外が行う |
| 永続 | docs正本主義、引き継ぎコンテキスト、成果物台帳 | gitのPRが調停役になる |
| 反復 | 週次のQCDレポート、工程ゲート | leaderが判定し、人間が承認する |
三列目に注目すると、受託開発でこれらを担っているのは、多くの場合AIではなく人間の運用そのものです。ここに、この記事で最も伝えたい点があります。
受託開発は、知識のグラフの構築費を先に払っている。
機能IDを振り、受入基準に紐づけ、設計書項番とテスト番号に連結した時点で、グラフの構築作業は終わっています。しかもそれは「グラフを作るため」にやったことではありません。検収に耐えるトレーサビリティが業務上必要だから作ったのであって、グラフは副産物として手に入っています。
RAG文脈のグラフ構築が難しいのは、この前払いがない文書が対象だからです。誰も構造化していないPDFやWikiから、機械が推測で実体と関係を取り出す。抽出の精度も名寄せの精度も保証がなく、検証工程が重くなるのは当然の帰結です。
受託開発の成果物は、その逆の位置にあります。ID体系が先にあり、承認記録がついていて、断絶があれば機械的に検出できる。だからこのパックはグラフDBを導入していません。grepと同梱の点検ツールで足りています。
ただし、限界は正直に書いておきます。
三つ目は、AI導入の効果が組織によって大きく違う理由でもあります。トレーサビリティを形式的に整えているだけの組織では、前払いの中身が空です。その状態で知識のグラフを名乗っても、AIが引くのは空の索引になります。
外の議論のうち、最も実務的なのは「探索をモデルに任せない」という指摘です。インデックスだけで候補を絞り、開くのは1〜2ファイルにして、モデルは考える仕事に使う。個人のノート環境ではこれが直接効きます。
受託開発でこれに対応する作業は、しかし索引の整備ではありません。正本を一つに決めることです。
同じ仕様が、要件定義書と基本設計書と課題管理表とチャットの決定事項に、少しずつ違う内容で四通り書かれている。この状態でどれだけ精緻な索引を作っても、引いた先が矛盾しているのでは意味がありません。索引は正本の上にしか成立しません。
並列の幅そのものより、突き合わせ先が先にあるかどうかで結果が変わる。
索引は正本の上にしか成立しない。探索の効率化はその後の話になる。
個人のノートと業務システムの決定的な差はここにあります。業務システムの正本は複数の組織にまたがって存在し、それぞれに承認記録がついています。「どれが正しいか」は技術的な問いではなく、誰が承認したかという契約上の問いです。
パックでは、docs配下の正本主義と、引き継ぎコンテキストがこれを担っています。v3.1.0では、この引き継ぎコンテキストの呼び名も変えました。旧称は「コンテキストヒストリー」でしたが、実体は履歴ではありません。本体は最新の状態を保持する一枚のファイルで、履歴はアーカイブ側に分かれています。名前が「過去ログ置き場」と誤読され、初見の担当者が最新状態を探しに行かないという実害が出ていました。
「記憶させるのではなく引かせる」という主張自体は、受託開発では新しいものではありません。属人的な記憶に頼らず正本を引くのは、もともとの作法です。AIが入って変わったのは、正本が整っていない組織のコストが即座に、しかも目に見える形で表面化するようになったことのほうだと考えています。
人間なら、四通りの記述を前にして「たぶんこれが最新だろう」と判断し、必要なら書いた人に確認します。AIは確認に来ずに、もっともらしいほうを選んで作り切ります。曖昧さの管理にQ-IDを振って台帳で追う設計にしているのは、この差を埋めるためです。
v3.1.0で最も分量を割いたのは、機能の追加ではなく用語の差し替えでした。
| 旧称 | 新しい呼び名 | 差し替えた理由 |
|---|---|---|
| 関所 | 承認ゲート／ガードレール | guardrail・approval gate は完全な標準語 |
| コンテキストヒストリー | 引き継ぎコンテキスト | handoff / persistent context。旧称は実体とずれていた |
| グラフ実行標準 | ワークフロー実行標準（並列オーケストレーション） | Claude Code側の正式名が dynamic workflows |
あわせて「爆風半径」というラベルを廃止しました。日本語として流通していない語であり、精査するとそもそもラベルが不要な箇所がほとんどでした。「外れた場合に壊れるもの」という説明文が定義そのものになっていて、別名を立てる必要がなかったのです。
ただし概念そのものは残しました。影響範囲（その問いが触れる機能IDと成果物、つまりいま何を巻き込んでいるか）と、外れた場合の影響（その仮定が誤っていた世界での被害の見積り）は別の概念です。前者は現在の事実、後者は反実仮想であり、混ぜると仮定の管理が雑になります。ラベルは畳んで、区別は本文に残しました。
独自語を作らない判断基準として、次の三つをテーラリングガイドに置いています。
独自性それ自体に価値はありません。一般語との落差が生むのは、外部の記事と読み合わせられないことと、新しく入った人が既存知識と接続できないことという、二つのコストだけです。日本の受託開発では、社内標準の独自語が長年かけて堆積している現場が珍しくありません。AIを入れると、この堆積が新しい形で効いてきます。学習済みの一般知識と接続できない語彙で書かれた標準は、AIにとっても文脈の断絶になるからです。
なお、検討のうえ残した独自語もあります。仮定マーカー（コードに「【仮定: Q-031】」を埋めてgrepで回収する運用に対応する一般語がない）、正本（SSOTに対応するが日本語の文書管理用語として正確）、QCD・IPA共通フレーム・V字（国内SIの標準語）、4層モデル（業界の三段整理に1層足した形で、初出で接続を書けば通る）の四つです。
ファイル名・スキル名・ディレクトリ名は据え置きました。導入済みの案件を壊さないためで、変えたのは呼び名だけです。
外の議論で繰り返し語られる絵のひとつが、夜のうちにエージェントを自動で回し、朝には昨日より良くなっている、というものです。
受託開発でこれを実施するとき、危険なのはループそのものではありません。目的関数です。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支援サービスで、SES・受託開発企業のAI駆動開発シフトをDelivery Scope+の並走モデルで支援しています。導入前の相談はお問い合わせからどうぞ。
v1.x から導入済みの案件については、docs配置に後方互換のない変更が入っています。移行手順はリポジトリの初期化スキルのフェーズ0にまとめてあります。