4 プロトコル設計原則

🧭 4. プロトコル設計原則

成功するプロトコルにはすべて、技術的決定を導く一連のコア信念があります——HTTP の「ステートレス」は Web を無限にスケールさせ、Markdown の「可読性優先」はソーステキストをレンダリングなしでも読めるようにしました。ICP も同様に6つのコア設計原則に従い、これらがプロトコルの技術哲学を定義し、後続のすべての設計選択を制約します。

原則1：アノテーションによる拡張、置換ではない

ICP は自然言語を置き換えるのではなく、自然言語の上に構造化アノテーションを重ねます。すべてのアノテーションを除去しても、元のテキストは完全に読める状態を維持します。

例えば、ユーザーが「!!今日の退勤前に!! プロジェクト週報 を @田中さん に送って」と言った場合。すべてのアノテーションマーカーを除去しても、この文は流暢な自然言語のままです。しかしアノテーションがあることで、システムは締切時間、重要コンテンツ、受信者を識別し、締切、添付ファイル、送信ボタン付きのアクションカードを生成できます。

原則2：端末非依存性

プロトコル自体は特定の端末の能力を前提としません。ICP は「何であるか」（セマンティックコンテンツ）のみを記述し、「どう表示するか」（レンダリング方法）は規定しません。

例えば、「経費精算書の承認」セマンティクスを含む同一の ICP ドキュメント：デスクトップではテーブルと添付ファイルプレビュー付きの大画面インターフェースとしてレンダリング、モバイルでは重要情報と2つのボタン（承認/差戻し）のみ表示、スマートスピーカーでは要約を音声で読み上げ音声確認を待機、AR グラスではユーザーの視野に承認通知がフローティング表示。

原則3：コンテキストの明示化

理解に影響するすべてのコンテキスト情報は、メッセージに明示的に付加されるべきです。プロトコルは AI の「空気を読む」能力に依存して暗黙の意味を推論しません。

原則4：段階的拡張

最もシンプルな ICP ドキュメントはプレーンテキストメッセージです。アノテーション、コンテキスト、レンダリングヒントはすべてオプションの拡張レイヤーであり、実装者は最もシンプルなサポートから始めて、段階的に能力を追加できます。

原則5：後方互換性

新バージョンのプロトコルは旧バージョンのドキュメントを処理できなければなりません。未知のアノテーションタイプはエラーを引き起こすのではなく、安全に無視されるべきです。

原則6：オープンな相互運用性

ICP は特定の AI モデル、プラットフォーム、ベンダーに縛られません。skills メカニズムを通じて、ICP は MCP（Model Context Protocol）、A2A（Agent-to-Agent）、OpenAPI などの既存プロトコルとブリッジ接続します。

ICP は接続レイヤーであり、閉じたエコシステムではありません。その価値は統一された人機インタラクションのセマンティック記述を提供することにあり、具体的な AI 推論、ツール呼び出し、エージェント間通信はそれぞれ得意なプロトコルに委ねます。