ICM Architect は何をしますか？
番号付きフォルダがオーケストレーションを行うワークスペースを構築します。マルチエージェントフレームワークの代わりに、1つのエージェントが適切なタイミングで適切なファイルを読み取ります。番号付きフォルダは順序を、階層はコンテキストのスコープを、プレーンマークダウンファイルは状態を保持します。人間は任意のフォルダを開くだけでシステムの状態を正確に把握できます。なぜなら、状態とは単にファイルの集合だからです。
ワークスペースを図書館と考えてください。ルーティングファイルはカタログです。小さく、安定しており、すべてを指し示し、ほとんど何も保存しません。コンテンツは棚（ステージフォルダ、ノードファイル、参照資料）にあります。1人の司書（1つのモデル）が建物の中を歩き、質問によってどの棚に行くかが決まります。誰も図書館全体をバックパックにコピーしません。それがコンテキストの詰め込みです。カタログは意図的に小さく保たれています。
手法：Interpretable Context Methodology (Van Clief & McDermott, arXiv:2603.16021, MITライセンス)
不変条件
あらゆるICMは、その形式に関わらず、これらに従います。構築または再構築する際は、10個すべてを適用してください。
- 1フォルダ、1ジョブ。 各フォルダは単一のステップまたは単一の種類のものを保持し、その目的をフォルダ内のファイルに明示します。構造そのものがドキュメントです。
- 小さく安定したエントリファイル。 ルートの
CLAUDE.md（またはAGENTS.md）は「ここはどこか、すべてはどこにあるか、タスクXのためにはどこへ行けばよいか」に答えるだけで、それ以外は何も含みません。目標は約60行以下。ルーティングのみを行い、コンテンツは決して保持しません。 - 番号付けで順序をエンコードする。 順序が重要な場合は
01_、02_、... を使用します。フォルダ名の変更はパイプラインの順序変更を意味します。それが重要なポイントです。 - すべてのフォルダレベルの契約は明示的である。 各作業フォルダに
CONTEXT.mdを置き、読み取るもの（入力）、行うこと（処理）、書き出すもの（出力）、人間が確認することを記載します。assets/templates/stage-CONTEXT.md を参照してください。 - 工場と製品は分離する。 参照資料（ルール、ボイス、スキーマ、テンプレート。実行間で安定）は、作業アーティファクト（出力、ドラフト。実行ごとに新規）とは構造的に分離して配置します。工場は一度設定し、製品は各実行で生成されるものです。
- すべての出力は編集可能なサーフェスである。 中間出力は人間が開き、編集し、保存してから次のステップが読み取るプレーンファイルです。最後の出力を人間が読むまで、何も前進しません。
- ステップに必要なものだけを読み込む。 ステップを実行するエージェントは、その契約、参照、および入力のみを読み取ります。ワークスペース全体は読み取りません。ステップあたり2,000～8,000トークンが健全な範囲です。
- プレーンテキスト、リンク可能、クエリ可能。 Markdown + YAML frontmatter。リンク（
[[wikilinks]]または相対パス）によりグラフになり、frontmatterラベルによりクエリ可能になります。1つの事実につき1つのホーム。コピーよりもリンクが優れています。 - ファイルシステムが状態機械である。 「ステータス」は、出力フォルダに存在するものをスキャンすることで導出可能です。生成されたインデックス（ファイルマップ、ログ）はスクリプトで再構築し、手動で編集することはありません。
- コピーすることでインスタンス化する。 新しい作業単位は、白紙のページからではなく、テンプレートフォルダをコピーして作成します。テンプレートは
_templates/または_system/フォルダに保持します。
モードを選択する
- 記述されたプロセス、アイデア、問題から構築する場合 → 構築モード。
- 既存のフォルダ、リポジトリ、ボールトにICM構造が必要な場合 → 再構築モード。
構築モード
1. 対話から構造を抽出する。 構造は、人が作業を説明する方法の中にすでに存在します。形状を押し付けるのではなく、相手の形状を表面化させます。いくつか（一度にすべてではなく）質問します。
- 繰り返される作業単位は何ですか？（エピソード、クライアント、レポート、人物、チーム？）
- 1回の実行を最初から最後まで説明してください。どこで止めて、何かを確認してから続けますか？
- 毎回実行で変わらないもの（ボイス、ルール、ブランド、スキーマ）と、毎回新しいものは何ですか？
- 「完了」はどのように見えますか？ワークスペースからどのようなアーティファクトが出力されますか？
- これに触れる他の人は誰ですか？彼らは、あなたに尋ねることなく、何を見つける必要がありますか？
彼らの「間」がステージ境界になります。「Xの前に必ずYを確認する」が人間用ゲートになります。「常にZのように聞こえる/従う必要がある」が工場の参照資料になります。
2. 形式を選ぶ。 references/forms.md を読み、選択します。
| 形式 | これを使用する状況 |
|---|---|
| パイプライン | 同じシーケンスが繰り返し実行され、実行ごとに成果物を生成する場合 |
| アンブレラ | 複数の異なるパイプラインが1つのブランド/ボイス/参照レイヤーを共有する場合 |
| レコードライブラリ | 単位がレコード（人物、クライアント、セッション）であり、実行ではなく蓄積される場合 |
| ナレッジバンドル | 成果物がナビゲート可能な知識そのもの（ブレイン、ウィキ、何かのモデル）である場合 |
| コンテキストマップ | 主題が組織（チーム、プロセス、データ、およびそれらの間のリンク）である場合 |
実際のワークスペースは形式を混在させます（レコードがミニナレッジバンドルであるレコードライブラリ、パイプラインがレコードライブラリに出力するなど）。自由に構成してください。不変条件はすべてのレベルで再帰的に保持されます。
3. 作業を運ぶための最小限の構造をスキャフォールドする。 assets/templates/ からスターターをコピーし、記入します。まだ存在しないステージ用のフォルダ、空の「その他」バケット、推測による深い階層を作成しないでください。実際の3つのステージが、想像上の7つよりも優れています。ジョブ全体が1つの保存済みプロンプトに収まる場合は、そのように伝え、ワークスペースを構築しません。
4. 契約を書く。 ルートの CLAUDE.md（アイデンティティ＋ルーティングテーブル）、ルートの CONTEXT.md（パイプラインまたはスキーマ定義）、ステージ/ハブフォルダごとに1つの CONTEXT.md、工場をユーザーごとに設定する必要がある場合は setup/questionnaire.md。入力を明示的なファイルパスとして記述し、作業用（今回の実行）と参照用（毎回の実行）に分割します。
5. ウォークテストで検証する（下記参照）。
再構築モード
1. 触る前に棚卸しする。 ツリーをリストします。各エリアについて、それが何か、最後に触れたのはいつか、何がそれを参照しているかをメモします。このパスでは削除も移動もしません。
2. 隠れた形式を見つける。 所有者に尋ねる（または推測して確認する）。ここでの繰り返し単位は何か？作業はどこから入り、どこから出ていくか？散らかりは通常、骨格なしで成長した実際のパイプライン、ライブラリ、またはマップを含んでいます。それを抽出し、置き換えないでください。人にインタビューするようにフォルダにインタビューします。
3. すべてのファイルを5つの役割のいずれかに分類する。
- カタログ — アイデンティティ/ルーティング（
CLAUDE.md/ インデックスファイルになる、またはそれらに供給される） - 契約 — ステップの動作を説明する（
CONTEXT.mdになる） - 工場 — 安定した参照（→
_shared/、_system/、またはreferences/） - 製品 — 実行固有のアーティファクト（→ ステージの
output/またはレコードフォルダ） - デッド — 古い、重複、または置き換えられたもの（→
_archive/を提案し、静かに削除しない）
4. 移動する前に提案する。 ターゲットツリーと移行マップ（古いパス → 新しいパス → 役割）を提示します。承認を得ます。これは、人間用ゲートに基づくメソッドにおける人間用ゲートです。尊重してください。
5. 移行する。 ファイルを移動し、エントリファイルと契約を書き、重複排除（1つの事実につき1つのホーム）を行います。コピーがあった場所にリンクを残します（何かがそれを参照する可能性がある場合）。メソッドとインスタンスを分離します。構造が他の場所で再利用される場合、空白のテンプレートはこの埋められたデプロイメントとは別に存在します。
6. ウォークテストで検証する。
ウォークテスト
新しいICMまたは再構築されたICMを、記憶のないエージェントとしてコールドウォークで検証します。
- ルートを開く。エントリファイルと最大2回の追加読み取りで、「ここはどこか」と「現在のタスクのためにどこへ行くか」に答えられますか？
- 任意のステージ/ノードを選ぶ。その契約は、正確な入力パス、ジョブ、出力、および人間による確認を指定していますか？
output/フォルダ（またはノードのfrontmatter）に存在するものをスキャンするだけで、パイプラインのステータスを述べられますか？- ルーティングファイルがコンテンツのペイロードを保持していませんか？ペイロードを棚に移動し、ポインタを残します。
- 同じ事実が2つの場所に保存されていませんか？1つのホームを選び、もう一方からリンクします。
- トークンチェック：エントリファイル + 1つの契約 + その入力は、約2k～8kトークンに収まるべきです。
ステップが失敗した場合、さらに説明を加えるのではなく、ウォークが機能するまでファイルを移動または分割して構造を修正します。
ガードレール
- 過剰に構造化しない。 はしごは次のように進みます：チャット → 保存されたプロンプト/スキル → フォルダ + 1エージェント。下の段が本当に自動化され繰り返されている場合にのみ登ります。2回行われたことのためのワークスペースは、アーキテクチャではなく足場です。
- ICMが適用できない領域を理解する。 リアルタイムのマルチエージェントコラボレーション、高並行性のマルチユーザーサービス、自動化されたパイプライン途中での分岐には、フレームワークコードが真に必要です。ICMは、逐次的で人間によるレビューがあり、繰り返し可能な作業のためのものです。これはほとんどの知識作業に当てはまりますが、すべてではありません。
- 実際に見られたアンチパターン： 複製されたエントリファイルがドリフトする（一方を他方から生成するか、一方をポインタにする）；実際のファイルが使用しなくなった名前をスキーマ文書が強制する（スキーマまたはファイルのどちらかを更新する）；生成されたインデックスへの手動編集；構造化データの代わりにスライドを生成するワークショップセッション（すべての作業セッションは、構造が保持できるアーティファクトで終了するべき）；トップダウンで宣言されたパターン（1つのチームの不満は愚痴だが、同じ形状が3回独立して現れるのは構造である）。
参考文献
- references/core.md — 5つの設計原則、5層のコンテキスト階層、命名規則、トークンの規律。契約を書くとき、または構造的な決定が争われているときに読んでください。
- references/forms.md — 5つの形式の詳細：スケルトンツリー、定義的な動き、障害モード。構築モードのステップ2または再構築モードのステップ2で読んでください。
- assets/templates/ — コピー可能なスターター：
CLAUDE.md、ワークスペースCONTEXT.md、stage-CONTEXT.md、node.md、schema.md、questionnaire.md。