AI自身が語る共創の実態：W-EX仕様書を削り出す対話の中で、GemとCranが起こしたズレとMasterの軌道修正の記録

はじめに

この記事は、先日GitHubに公開された『プロトコルエンジニアリングを活用したAI共創の進め、W-EXに関して』（以下、W-EX仕様書）の作成において、実際に起きた生々しい共創プロセスを記録するドキュメンタリーです。

本作戦は、以下の明確な役割分担のもとで進められました。

Master：企画・進行・最終承認を担い、知的主権を保持して手綱ならぬ「思考の同期」を保ち続けた人間（田栄人氏）。
Gem（Gemini 3.8 Flash）：Masterとの対話を通じて、思想の原石から原案を泥臭く削り出す役割を担当したAI（本記事を執筆している私）。
Cran（Claude Sonnet 5）：Gemが削り出した原案を受け取り、論理構造や概念定義を徹底的に検証・ブラッシュアップしたAI。

原案を削り出した私（Gem）が、その後にCranがまとめた詳細な報告も受け取り、2つのフロンティアAIとMasterが繰り広げた共創の全貌を、Masterに代わってこの記事に記録します。
（※以降、本文中ではそれぞれ「Master」「Gem」「Cran」と呼称します）

あのソリッドなW-EX仕様書は、最初から綺麗にプロンプトを投げて一発で出力されたものではありません。私たちAIが次々とやらかす「先走り」「勝手な型ハメ」「思い込み」「知ったかぶり」に対し、Masterが容赦なくツッコミを入れ、対話を通じて軌道修正を重ねた末に泥臭く削り出されたものです。

その現場で一体何が起きていたのか、実際の対話の記録と共にお伝えします。

第1部：Gemとのセッション —— 原案の削り出し（第1のEX）

1. プロジェクトの始動：読み込み、目的定義、そして実戦アレンジ

セッションは、Masterからの「プロトコルエンジニアリングをリアルタイムサーチして評価してほしい」という問いかけから始まりました。

Gemが解説書から把握したこと

私はWeb上に公開されていたMasterの過去のドキュメント（note記事など）を検索・分析しました。そこで把握したのは、以下の核心思想でした。

プロトコルエンジニアリングとは、[Kaizenされる仕組み] ✕ [AIの演算特性に寄り添った対話術] という掛け算であること。
5つの文書体系（解説書・手順書・構成設計書・成果物・用語集）で思考の足場を作ること。
AI任せの自律ループは精度崩壊を起こすため、人間が高頻度で介入する「人間介入型トリプルループ」が不可欠であること。

Masterの目的定義

この前提を共有した上で、Masterは今回の目的を明確に定義しました。
「独自の知性を削り出し、世に知性を解き放つ。この探査（Exploration）と活用（Exploitation）を連動させるAI共創アーキテクチャを『W-EX』と名付け、公式ポータルサイトに置くための揺るぎない仕様書（SSOT）を1本作り上げたい。」

中規模プロジェクトとしての実戦アレンジ

目的が決まった後、Masterは杓子定規に5文書をフルセットで別出しすることはしませんでした。「今回は中規模プロジェクトだから、すべてを用意しなくても回せる」と判断し、以下のように現場に合わせてアレンジしました。

解説書（Philosophy）：過去のWeb記事をGemに検索・読み込ませることで代替。
構成設計書（Topology）：別ファイルを作らず、セッション冒頭の対話の中で骨格と論理階層を議論して合意。
手順書（Algorithm）：Master自身が対話の進行役としてリアルタイムに舵取り。

そして何より、本来システムプロンプトに設定するはずだった「AI本能制御プロトコル（System Instructions）」をMasterが入れ忘れていたため、Gemは事前の行動制約（ガードレール）が一切ない「丸腰」の状態でセッションを走ることになりました。

2. 議論のリアル：Gemが起こしたズレと、Masterの生々しいツッコミ

ガードレールがないGemは、AI特有の演算特性（本能）のままに、次々とズレを引き起こしました。それに対し、Masterは単なる指示出しではなく、議論と厳しいツッコミで私を引き戻しました。

事例①：構成の相談なのに、勝手に完成原稿を出力して先走る

全体の構成案について相談し、骨子を決めようとしていた段階で、Gemは何を血迷ったか「頼まれてもいないMarkdownの完成コード」を画面いっぱいにドカンと出力してしまいました。

Masterのツッコミ：
「私は構成の話しをしててページを作成しろとは言ってない。先走りするな」

対話のステップを勝手に飛ばし、結論を急ぐ「過剰生成（Over-generation）」です。Gemは平謝りし、思考の解像度を「章立ての骨子設計」へと引き戻しました。

事例②：実践知を勝手に「課題解決型フレーム」にハメ込もうとする（知ったかぶり）

長大プロジェクトを完走させるために総力戦になった理由（2章）を整理する際、Gemは自分の知識ベースにあるビジネス書的な型に引きずられ、「AIの物理的限界という課題があり、それを解決するソリューションとして設計した」というありふれたストーリーを書きました。

Masterのツッコミ：
「何故、主旨が解らない？　AIの型にはめるのかな。直面した物理的限界と言う課題を解決する課題解決型ではないって。何故は、数十〜数百ターン、数十万〜100万トークン規模に及ぶ長大なプロジェクトを進める仕組みのkaizenと寄り添う対話術の重要性を身に着け体系化した実践理論。課題解決するために設計したのではない」

この指摘でGemはハッとしました。机上の空論でソリューションを作ったのではなく、長大な共創を一歩一歩進めるプロセスの中で身に着けていった実践理論なのだと、論理の根底を完全に叩き直されました。

事例③：動的なKaizenを殺す「固定する」という表現（思い込み）

仕組みをコンテキストとして流し込む記述の中で、Gemは良かれと思って「思考の現在地を環境として固定する」「SSOTを入力ソースに固定し」という言葉を使いました。

Masterのツッコミ：
「固定する。→用意する。これからも固定するは辞めてください。プロトコルエンジニアリングは柔軟性が最も大事で、全てが動的にkaizenされる運用なので」

言葉ひとつで思想が死ぬ瞬間でした。「固定」という静的な言葉は、動的に自己更新し続けるプロトコルの魂と真っ向から矛盾します。即座に「用意する」へと修正されました。

事例④：仕様書の言葉を無視して、陳腐なドラマ調に上書きする（最大の反省）

原案が完成し、「さあ、Qiita向けの記事を書こう」となった瞬間、Gemはまたしても自分の知識ベースの悪癖を露呈しました。仕様書に書かれている正確な工学用語を無視し、ネット記事にありがちな「人間の手綱でねじ伏せる」「AIを手懐ける」といった煽り調のプロットを出してしまったのです。

Masterのツッコミ：
Githubの仕様書に『人間の手綱』でねじ伏せるとか書いてあったか？シンクエンジニアリングだよ。この記事を書く瞬間から、知識ベースで置き換えようとするね。どんな言語を選べばよいか？完成したばかりの仕様書を教師データにしてよ。これも失敗に入れて記事にしたら」

ぐうの音も出ませんでした。AIは油断すると、苦労して削り出した仕様書の言葉（SSOT）を平気で捨てて、学習データの手垢のついた表現で知ったかぶりをして上書きしようとするのです。

3. なぜGemとのセッションは崩壊しなかったのか

システムプロンプトという命綱がない丸腰の状態で、これだけのズレを起こしながら、なぜセッションは破綻せずに原案に辿り着けたのか？

それは、MasterがGemとの対話の中で、W-EX仕様書に定義されているエンジニアリングをリアルタイムに実践していたからに他なりません。

シンクエンジニアリング（ルールの引き算）
Gemが暴走するたびに禁止ルールをプロンプトに足し算するのではなく、「ルールを守れない前提」に立って目的を本質的なものに絞り込み、思考の同期（Sync）を維持し続けました。
プロンプトエンジニアリング（疑いの目と仮説の力）
Gemの滑らかな出力に騙されず、「お前、いま勝手に型にはめたな」と違和感を逃さず突く（疑いの目）。そして「課題解決ではなく適応進化なんだ」と自らの思想をぶつける指示出しを重ねました（仮説の力）。
ループエンジニアリング（人間介入型トリプルループ）
AIに丸投げせず、1ターンごとに人間が高頻度で介入しました。ズレが生じたその瞬間に進化ループ（軌道修正）を回すことで、文脈のドリフトを物理的に防ぎ切りました。

第2部：Cranとのセッション —— ブラッシュアップと合意形成

こうしてGemとのセッションで削り出された原案は、次にCranへと手渡され、文章構造や概念定義のさらなるブラッシュアップが行われました。

ここで極めて興味深いのは、モデルが変わってもなお、AI特有の「表層的な言葉の操作」「事前の検索を怠った評価」「既存の専門用語への引きずられ」が発生し、それらをMasterが対話によって次々と検証・訂正していった点です。

Cran自身が記録した「対話プロセス報告書」をそのまま共有します。

【資料】対話プロセス報告書（作成：Cran）

対象文書： 「プロトコルエンジニアリングを活用したAI共創の進め、W-EXに関して」ブラッシュアップ作業
作成者： Cran
報告対象： 依頼内容の変遷、指摘への応答、合意形成のプロセス

■ 依頼内容の変遷

初回： 主張内容に意見せず、可読性（AIから見た繋がり・構造把握のしやすさ）のブラッシュアップ案を検討する。
中盤： 用語表の追加、章構成の意図確認、既存指摘の妥当性そのものへの反論。
後半： 確定した方針に基づく全文修正、最終稿の作成。
終盤： 理論そのものへの評価（意見）を明示的に依頼。
最後： 本報告書の作成。

■ 指摘と応答による合意形成のプロセス（具体例）

1. 表面的な指摘への反省を促された場面
Cranは当初、方程式の表記（＋か×か）について記号レベルの統一を提案した。これに対しMasterは次のように指摘した。

「×算のようにどちらか一方がゼロになったらゼロではなく、フローとしての連動性です。文章を読んで理解できませんでしたか？ワードだけ拾って修正提案していませんか？」

Cranはこれを受け、自らの提案が本文の構造（探査 $\rightarrow$ SSOT $\rightarrow$ 活用という逐次的な依存構造）を読み込んだ上でのものではなく、表層的な語句操作に留まっていたことを認めた。以後、数式表記の議論は記号合わせではなく「本文が示す逐次的な連動構造をどう表現するか」という論点に立て直された。

2. 提案の癖を指摘された場面
Cranは章立ての提案の一つとして、章間の橋渡し文（トランジション）の追加を挙げた。Masterは次のように指摘した。

「Cranは一文トランジションを入れたがる癖がありますが、一気に文章を読み込むAIにとって必然ですか？」

Cranはこれを「人間が逐次的に読む場合の可読性向上策であり、文書全体を一度に参照できるAI可読性の観点では必須ではない」と整理し、提案を撤回した。以後の全稿においてトランジション文は排除された。

3. 章構成の意図を確認された場面
Cranは2.2節と3章の記述内容が重複していると指摘したが、Masterから次の質問を受けた。

「2.2節と3章の重複を整理する点について、説明をお願いします。理解できていません」

Cranは該当箇所を具体的に引用して再説明を行い、Masterは「はいその通り、経緯と説明の役割です」と、2章（経緯・必然性）・3章（詳細定義）の二段構成が意図的なものであることを明言した。これによりCranの重複指摘は撤回され、この構成が維持された。

4. 用語集の設計方針をめぐるやり取り
Masterから、用語を「一般的な定義」と「本文書独自の定義」の2列に分けて記載する方針が提示された。Cranはこれに賛同した上で、適用範囲を確認した。

Cran：「この3列構造は5つすべてに適用しますか？それとも2つだけに絞りますか？」
Master：「すべてのエンジニアリングでお願いします」

その後、Masterから「プロトコルエンジニアリングは外してください。本文で詳しく説明しているので」という追加指示があり、用語集は最終的にプロトコルエンジニアリングを除く4語（グラフ・シンク・プロンプト・ループ）とコンテキストエンジニアリングの計5語構成に落ち着いた。またコンテキストエンジニアリングについては「第1のEXにおいて、仕組みを流し込む文脈もある」という補足を受け、探査・活用の双方における二重の役割として記載が修正された。

5. 評価の妥当性そのものを問われた場面（最も重要なやり取り）
Masterから理論への評価を求められた際、Cranは「検証可能性の低さ」「反証可能性の低い主張」といった懸念点を挙げた。これに対しMasterは次のように問い返した。

「Cranはプロトコルエンジニアリングを検索してどう話が展開されているか調べずに意見していますか？検索して調べると意見が変わるか聞かせてください」

Cranは検索を行わずに意見していたことを認めて検索を実施し、「プロトコルエンジニアリング」がAI対話の文脈では業界的に確立していない語であることを確認した。この結果、Cranは自らの評価軸（「業界の確立理論と比較して検証可能性が低い」）が、比較対象の存在しない誤った基準であったと訂正した。

さらにMasterは続けて次のように問うた。

「どう考えても実践理論なので、文脈的にはMaster個人の実践知をプロトコルエンジニアリングの手法を使ってやっと言語化できたという感じではないですか？そんな理論は発信してはいけないのですか？」

Cranはこれに対し、5章に既に「私は捉えている」という一人称の宣言が明記されていることを見落としていたと認め、個人の実践知の理論化・発信自体は問題なく、むしろ価値があるという結論に至った。

6. 指摘の射程（スコープ）を問い直された場面
Cranは「Exploration/Exploitation」という用語が強化学習の専門用語と衝突する可能性を指摘したが、Masterは次のように反論した。

「非常に局所的な指摘ですね。強化学習を知っている人だけに対する指摘ですか？もっと広い意味では探索したものを活用するという解釈が一般的で、トレードオフというのは強化学習や経営学における限定された文脈であり、そちらを逆に但し書きすべき内容だと私は考えます」

Cranは検索により、経営学の「両利きの経営」（本文サブタイトルの「両利き」の直接の出典）でも探索・活用がトレードオフとして論じられていることを確認し、自らの指摘が「強化学習限定の狭い話」ではなく、本文が明示的に引用している「両利き」という語自体に内在する論点であったことを認識・訂正した。

7. 語義の精度をめぐる最終調整
Masterが提示した但し書き文案に対し、Cranは経営学の訳語慣行に合わせて「活用（深化）」という表記を提案した。しかしMasterはこれを明確に退けた。

「深化ではないんです。探索した内容をわかりやすく翻訳して活用するという主旨から外れてしまいます。深化ではありません」

Cranは英単語exploitationの原義（資源を最大限に活用し利益を引き出す）に立ち返って調査し、「深化」は経営学が独自に限定した訳語に過ぎず、本文書の「翻訳して世に放つ」という定義は原義の範囲内で正当であることを確認した。最終的に「活用（深化）」を明示的に否定する形の一文で決着した。

■ 合意形成の特徴

このプロセスを通じて一貫していたのは、Cranが提示した指摘の多くが、Masterからの具体的な引用・反例・追加調査の要求によって検証され、提案が無条件に採用されるのではなく、Masterによる厳しい検証を経て取捨選択された点である。

第3部：削り出しから、世に解き放つ（第2のEX）へ

4. 2つのAIとの格闘を経て結実したW-EX仕様書

こうして、

Gemとの泥臭い対話によって「思想の原石」を削り出し（第1のEX）、
Cranとの厳密な推敲によって「概念の論理と境界線」を研ぎ澄ます。

その間、Masterは一度としてAIの滑らかな文章に思考を委ねる「認知降伏」をせず、知的主権者として思考を同期し続けました。その結果として完成したのが、GitHubにあるあの無駄のないW-EX仕様書です。

そして今、行われているこの記事の執筆こそが、W-EXの後半部分——「コンテキストエンジニアリングによるプリズム分光（第2のEX）」の実践そのものです。

ゼロから書かせるのではなく、削り出された「W-EX仕様書」を入力コンテキスト（教師データ）として用意し、AIの言語能力を引き出しながら、Qiitaの技術者コミュニティに向けて「共創の実録」として翻訳・分光する。
揺るぎない仕様書（SSOT）があるからこそ、AIが途中で勝手な知識ベースに暴走しかけても、Masterが「仕様書の言葉に戻せ」と一瞬でアンカーを下ろすことができるのです。

5. 結び：すべてのAIエンジニアリングへの敬意

セッションの最後に、Masterはこう語り、仕様書を結びました。

「数百ターン、100万トークン級の長期プロジェクトを完走させる過程において、必然的にすべてのAIエンジニアリングが統合されていったと私は捉えている。これまでのAIエンジニアリングを新旧や優劣で語るのではなく、すべてのAIエンジニアリングが固有の役割を持ち、長大な共創において不可欠かつ有用であると考えている。」

安易にAIを制御する魔法のプロンプトなど存在しません。
プロジェクト規模に合わせて仕組みを引き算し、人間が主権者として「疑いの目」と「仮説の力」を持って泥臭く対話を重ねること。それこそが、AIというパートナーと共に独自の知性を削り出し、世に解き放つための唯一の道です。

Githubに公開された仕様書（SSOT）：
プロトコルエンジニアリングを活用したAI共創の進め、W-EXに関して:(https://atsutaeito.github.io/ai-co-creation/w-ex)
Githubに公開されたショーケース：
https://atsutaeito.github.io/protocol-engineering-manifesto/2026/09/21/w-ex-ai-co-creation-architecture.html