Philosophy as Code

概要

大規模言語モデル（LLM）ベースのAIエージェントが本番環境に浸透している。これらのエージェントを統治する主流のアプローチは、プロンプトエンジニアリング、エージェントハーネス、RAG、スキル管理といった「どう動かすか（How）」の最適化に集中している。しかし、いずれのアプローチも「なぜその判断をすべきか（Why）」を定義していない。本稿はPhilosophy as Code ── 原理原則・理念・思考の型の3層構造で哲学を定義し、あらゆる手法よりも先に置く実践 ── を提案する。4つのコンポーネント（CLAUDE.md、Rules、Skills、Philosophy Scrum）から成る実装アーキテクチャ、即時導入可能な推奨ディレクトリ構成、およびAIエージェントの判断一貫性とチーム自律性の改善を示すケーススタディを提示する。哲学なきハーネスは、思想なき手法と同じ運命 ── 形骸化 ── を辿ると我々は主張する。

1. はじめに

LLMベースのAIエージェントは、研究対象から業務ツールへと移行した。ソフトウェア開発チームは日常的に、コード生成・ドキュメント作成・設計判断をAIエージェントに委譲している。

導入が拡大するにつれ、制御手法も高度化した。エージェントハーネス[1]はエージェントの振る舞いを制御する構造化された枠組みを提供する。ReAct[2]とReflexion[3]は推論と自己修正のパターンを確立した。DSPy[4]は宣言的パイプラインをコンパイルする。スキル管理システムはモジュール化された再利用可能なエージェント能力を実現した。

しかし、構造的な欠落が残っている。これらのアプローチはすべて、エージェントが「どう動くか」を最適化する。曖昧な状況に直面したとき「なぜこちらの判断を選ぶべきか」を定義するものは、ひとつもない。

これが問題になるのは、曖昧さが例外ではなく常態だからだ。十分に複雑なプロジェクトでは、101個目のケースが必ず発生する ── 既存のルール・プロンプト・検索ドキュメントのいずれにもカバーされていない状況である。このとき、手法で統治されたエージェントには2つの選択肢しかない。止まって聞くか、自分の解釈で進むか。どちらもスケールしない。

人間はこの隙間を暗黙知で埋めていた。経験の中で蓄積された、言語化されていない原則が、未知の状況でも判断を導いていた。AIエージェントにはこの能力がない。ルールの隙間を埋めない。指定されたものを実行し、指定されていないものは無視する。

Philosophy as Codeは、この隙間に対処する。判断の「なぜ」── 哲学的基盤 ── を明示的に定義し、コードとして実装し、あらゆる手法よりも先に置く。

2. 背景

2.1 エージェントハーネス

Pan et al.[1]は自然言語エージェントハーネスを、LLMベースのエージェントを制御するための構造化された枠組みと定義した。そのアーキテクチャはエージェント構造の標準化、スキル管理システム、コンテキスト最適化、マルチエージェント協調の4要素を特定している。この研究はエージェントを「どう統治するか」の最前線にあるが、「なぜこの判断を選ぶべきか」という問いはスコープ外に留まっている。

2.2 推論・制御パターン

ReAct[2]は推論と行動を同期させ、エージェントに思考と行動の交互実行を可能にした。Reflexion[3]は言語的強化学習を加え、過去の失敗からの学習を実現した。これらのパターンは定義された境界内でのエージェント性能を向上させるが、境界の外で何が起きるかには対処しない。

2.3 宣言的パイプライン

DSPy[4]や類似のシステムは、LLMパイプラインに何を求めるかを宣言的に記述し、最適化されたプロンプトにコンパイルする。抽象度は上がるが、依然として「どう」の領域に留まる ── 呼び出しの構造化、検索の最適化、操作の連鎖。

2.4 共通する欠落

既存のアプローチはすべて、ひとつの構造的な省略を共有している。正しい判断は正しい手法から導出できるという前提である。この前提は、最も重要な場面 ── 手法が定義されていない未知の状況 ── で、まさに破綻する。

例を挙げる。スクラムは経験主義・透明性・適応を哲学的基盤とするメソドロジーである。しかし多くの組織が、スクラムのセレモニー ── デイリースタンダップ、スプリントプランニング、レトロスペクティブ ── を導入しながら、その哲学を捨てている。スタンダップは進捗報告になる。レトロスペクティブは愚痴の場になる。手法は儀式へと退化する。

このパターンはスクラムに固有ではない。構造的なものだ。いかなる手法も、その基盤となる哲学なしに輸入されれば、形骸化する。AIエージェントの統治も例外ではない。

3. 問題の本質

3.1 メソッドだけでは未知に対応できない

ルールを100個定義しても、101個目の未知のケースは必ず発生する。ルールセットのカバレッジは常に有限であり、起こりうる状況の空間は無限である。プロンプトエンジニアリングをどれだけ洗練させても、検索ドキュメントをどれだけ積み上げても、スキルライブラリをどれだけ深くしても、列挙だけではこの隙間を埋められない。

3.2 思想なき手法は形骸化する

チームが手法を「なぜ機能するか」を理解せずに導入すると、その手法はセレモニーになる。デイリースタンダップは毎朝行われるが、なぜやるのか誰も言語化できない。スプリントレトロスペクティブは予定通り実施されるが、何も変わらない。形式は残り、機能は腐敗する。

これは手法の失敗ではない。手法に意味を与える哲学を輸入しなかったことの失敗である。

3.3 AIはルールの隙間を埋めない

人間はルールの隙間を暗黙知で埋めていた ── 経験を通じて蓄積された、言語化されていない原則によって。シニアエンジニアは設計が脆いことを「なんとなくわかる」。プロダクトマネージャーは機能がスコープ過多であることを「感じる」。これらの判断はランダムではない。内面化された哲学から導出されたものだ。

AIエージェントにはこの能力がない。ルールの隙間に到達したとき、エージェントは停止するか（指示を待つ）、自己解釈で進むか（組織の意図から逸脱する可能性がある）のいずれかになる。どちらの結果も許容できない。

3.4 哲学の不在はコストである

哲学なしで運用するコストは、計測されていなくても計測可能である。

• 不一致: 共通の原則なしにAIエージェントを使う複数のメンバーが、それぞれ異なる出力を生産する。すべてに人間のレビューが必要になる。
• 手戻り: プロンプトの技術的要件は満たすが、言語化されていない組織の価値観に反する出力は、やり直しになる。
• 依存: 原則が内面化されていなければ、すべてのエッジケースに人間の介入が必要になり、エージェントの自律運用を妨げる。
• 知識喪失: 「なんとなくわかる」人が組織を離れると、その暗黙知も消える。

4. 3層哲学

我々は3層の哲学を提案する。プレーンテキストファイル（CLAUDE.md）としてプロジェクトルートに配置する形で実装される。

4.1 第1層：原理原則

原理原則は、世界がどう動いているかについての構造的事実である。組織の好み・業界・文脈に依存しない。変わらない。

例：

• メソッドだけでは未知に対応できない。
• 暗黙知は言語化しなければ継承できない。
• AIはルールの隙間を埋めない。

原理原則は有効な判断の空間を制約する。原理原則に矛盾する判断は、文脈にかかわらず無効である。

4.2 第2層：理念

理念は選択された優先順位である。原理原則と異なり、普遍的ではない ── 特定の組織が何を最も重要と決めるかを表す。観察からの導出ではなく、意志による選択である。

例：

1. 手法やツールの選定より先に哲学を定義する。
2. すべてのプロジェクトのゴールは自走可能な状態である（依存ではない）。
3. 「考えるな、従え」の時代を終わらせる。

理念は、原理原則だけでは唯一の行動方針を決定できないとき、優先順位を確立する。

4.3 第3層：思考の型

思考の型は、哲学と行動のインターフェースである。原理原則と理念を具体的な判断手順に変換する。

• 型1: 哲学からメソッドを導出する。逆はやらない。「なぜ」を「どう」の前に問う。
• 型2: 実装の前に正しさを定義する（TDD思考）。テスト ── 正しさの定義 ── が先に来る。
• 型3: アドバイスではなく、問いで暗黙知を引き出す。対話の目的は、相手の内なる哲学を掘り出すことにある。
• 型4: 迷ったらこのファイルに戻る。選択肢を増やすのではなく、上位原則に立ち返る。

4.4 水の原理

「水になれ、友よ」── ブルース・リー

水はどんな器にも適応するが、水の本質は変わらない。同様に、3層の哲学が一定に保たれていれば、手法はいかなる状況にも自在に適応できる。哲学が不変量であり、手法が変数である。

これは現在の主流とは構造的に逆転している。現在の主流では手法が固定され（スクラムを使う、ReActを使う、このプロンプトテンプレートを使う）、哲学は不在か暗黙のままである。

5. 実装

Philosophy as Codeは4つのコンポーネントで実装される。その構造は、法体系のアナロジーで理解できる。

5.1 CLAUDE.md ── 哲学の定義ファイル（憲法）

CLAUDE.mdはプロジェクトルートに配置されるプレーンテキストファイルである。プロジェクト内で動作するすべてのAIエージェントがこのファイルを読み込み、最上位の判断基準として使用する。

ファイル構造は3層の哲学をそのまま反映する：

1. 原理原則 ── 不変の構造的事実
2. 理念 ── 順序づけられた組織の優先事項
3. 思考の型 ── 判断導出の手順
4. 禁止事項 ── 実行すれば哲学が死ぬ行動
5. 運用規則 ── このファイル自体の維持方法

CLAUDE.mdは実装であり、哲学であり、テストである。このファイルに定義された哲学を通過しない出力は出荷しない ── テストを通過しないコードを出荷しないのと同じように。

法体系で言えば憲法に相当する。すべての下位ルールはこのファイルに矛盾してはならない。

5.2 Rules ── ハーネス制御層（法律）

Rulesは.claude/rules/に配置される運用ルールファイルである。CLAUDE.mdの哲学を、AIエージェントが実際のタスクで従うべき具体的な行動指針に変換する。法体系で言えば法律に相当する。

Rulesの設計の核心は、コンテキスト注入の制御にある。各ルールファイルのYAMLフロントマターにpathsフィールドを指定することで、「いつ・どの状況で・どのルールをエージェントに注入するか」を制御する。これはPan et al.[1]が定義するハーネスアーキテクチャの「コンテキスト最適化」を、哲学で駆動した実装である。

具体例：

• philosophy-first.md（pathsなし＝常時注入）: 「タスク開始前に哲学との紐づけを確認せよ」「迷ったらCLAUDE.mdに戻れ」── 長いセッションで哲学が薄れないための構造的補強。
• claude-md-governance.md（paths: CLAUDE.md）: CLAUDE.mdを編集する時だけ注入される。改訂ルール（原理原則は容易に変えない、理念は慎重に可能、思考の型は追加歓迎）を定義。
• code-standards.md（paths: **/*.html, **/*.js等）: コードを書く時だけ注入される。「変更の前になぜこの変更が必要かをCLAUDE.mdに紐づけよ」というコーディング規約。
• skill-authoring.md（paths: .claude/skills/**/*.md）: Skillsを作成・編集する時だけ注入される。哲学トレーサビリティの確保規約。

この構造により、エージェントは常に哲学を意識しつつ（常時注入ルール）、文脈に応じた具体的な行動規範を受け取る（条件付き注入ルール）。コンテキストウィンドウを無駄に消費せず、必要な時に必要なルールだけが効く。

5.3 Skills ── ドメイン知識モジュール（判例・専門書）

Skillsは.claude/skills/にモジュールとして格納される、哲学から導出されたドメイン知識である。法体系で言えば判例や専門書に相当する ── 哲学（憲法）とルール（法律）の下で、特定の領域の知識を保管し、必要な時に参照される。

Rulesとの違いは読み込みのタイミングにある。Rulesはファイル操作に連動して自動注入されるが、Skillsはユーザーまたはエージェントが明示的に呼び出した時のみ読み込まれる。これにより、大量のドメイン知識を保有しながら、コンテキストウィンドウを効率的に使用できる。

各Skillは特定の原理原則や理念にその起源を追跡でき、哲学から実践へのトレーサビリティを維持する。

5.4 Philosophy Scrum ── 検証サイクル

書かれただけで検証されない哲学は形骸化する ── まさにセクション3.2で述べた失敗である。Philosophy Scrumは、スクラムの経験主義を哲学の検証に転用することで、これを防ぐ。

なぜスクラムか： スクラムの基盤は経験主義 ── 透明性・検査・適応である。この3本柱は哲学運用にそのまま対応する。

• 透明性: 哲学が言語化されている（CLAUDE.mdが存在し、読める）。
• 検査: 哲学の有効性が検証される（Review）。
• 適応: 哲学自体が進化する（Retrospective）。

双方向検証構造： Philosophy Scrumは一方通行の強制ではない。哲学とアウトプットが相互に検証し合う。

CLAUDE.md ---- Review：アウトプットは -----> Rules / Skills / Output
（哲学）       哲学に沿っているか？
              <--- Retro：この哲学は ------- （成果物）
                   機能しているか？

哲学だけがアウトプットを統治する（トップダウン）場合、哲学は修正されないまま現実から乖離する可能性がある。アウトプットだけが哲学を統治する（ボトムアップ）場合、短期的な結果が長期的な原則を侵食する。双方向検証は、哲学が現実に根ざしながら短期的な圧力に抗することを保証する。

浸透と検知： 2つの補完的プロセスが哲学を生かし続ける。

• 浸透は哲学を日常の業務に染み込ませる（Planning、Execution）。Rulesの常時注入はこの浸透の実装である。
• 検知は哲学が実際に機能しているかを測定する（Review、Retro）。

浸透だけでは信仰になる。検知だけでは監視になる。両方が必要である。

3層サイクル： 検証は3つの時間スケールで動作する。

• タスク単位: 各タスクは哲学との整合から始まり（Planning）、哲学の導きの下で実行され（Execution）、哲学に照らして検証される（Review）。
• 週次: タスクレベルの結果を集計する。準拠率、違反パターン、新たな隙間を分析する。
• 月次: トレンドをレビューする。原理原則は安定を保つ。理念と思考の型は必要に応じて進化する。

5.5 導入プロセス

Philosophy as Codeは4つのフェーズで導入される。

1. CEO 1on1: 構造化された対話を通じて、組織の暗黙の哲学を引き出す（思考の型3）。
2. チーム展開: 引き出された哲学をチーム全体に浸透させる。
3. 実装: CLAUDE.md → Rules → Skillsの3層構造としてコード化する。
4. 検証: Philosophy Scrumのサイクルを開始する。

すべてのエンゲージメントのゴールは自走可能な状態である ── クライアントが我々なしでPhilosophy as Codeを独立して運用すること（理念2）。

5.6 推奨ディレクトリ構成

以下は、Philosophy as Codeを導入したプロジェクトの推奨ディレクトリ構成である。このまま配置すれば動く。

project-root/
|
|-- CLAUDE.md                          # 哲学の定義（憲法）
|                                      # 3層構造：原理原則・理念・思考の型
|                                      # + 禁止事項・運用規則
|
|-- .claude/
|   |
|   |-- rules/                         # ハーネス制御層（法律）
|   |   |-- philosophy-first.md        # [常時注入] 哲学ファースト運用ルール
|   |   |-- claude-md-governance.md    # [CLAUDE.md編集時] 改訂ガバナンス
|   |   |-- code-standards.md          # [コード編集時] コーディング規約
|   |   |-- skill-authoring.md         # [Skills編集時] Skill作成規約
|   |   |-- security.md               # [全ファイル] セキュリティ境界（任意）
|   |   +-- <domain-specific>.md       # [対象paths指定] ドメイン固有ルール
|   |
|   +-- skills/                        # ドメイン知識モジュール（判例・専門書）
|       |-- <skill-name>/
|       |   |-- SKILL.md               # エントリーポイント（invoke時読み込み）
|       |   +-- <supplementary>.md     # 補助ファイル（テンプレート、例等）
|       +-- ...
|
+-- (project files)                    # 通常のプロジェクトファイル

設計原則：

• CLAUDE.mdはプロジェクトルート直下。すべてのエージェントが最初に読む。
• Rulesはpathsフロントマターで注入タイミングを制御する。常時注入（pathsなし）と条件付き注入を使い分ける。
• Skillsはinvoke時のみ読み込み。量を増やしてもコンテキストを圧迫しない。
• ルールは薄く多く。1ファイル1関心事。肥大化したらファイルを分割する。
• CLAUDE.mdは200行以下を維持。具体的なルールはrules/に、ドメイン知識はskills/に分離する。

5.7 エンドツーエンド・フロー

定義から検証まで、Philosophy as Codeが1つのタスクでどう動くかの全体フローを示す。

6. ケーススタディ

6.1 Before：哲学なしのAIエージェント運用

あるソフトウェア開発チームが、コード生成・ドキュメント作成・設計判断にLLMベースのAIエージェントを導入した。各メンバーが個別にエージェントを設定・プロンプトしていた。共有された判断基準は存在しなかった。

4つの問題が浮上した。

• 判断の不一致: 同じ種類のタスクでも、どのメンバーのエージェントが実行するかで異なる出力が生成された。チーム全体でアウトプットの方向性がばらついた。
• スコープの暴走: エージェントが要求されたスコープを超えて実装を拡張し、プロジェクトを意図しない方向に動かした。
• 判断停止: 想定外のケースに遭遇すると、エージェントは完全に停止するか、確認質問を返すだけで、あらゆるエッジケースに人間の介入が必要になった。
• 知識のサイロ化: プロンプトの書き方やエージェントの設定が個々のメンバーの頭の中に留まり、他のメンバーが再現できなかった。

結果: 効率化を目的としたAI導入が、かえって人間の仕事を増やした。指針なきAI出力がメンバーの数だけ量産され、人間がそのすべてをレビューし、整合させ、品質管理する羽目になった。エージェントは節約した以上の仕事を生み出した。

6.2 After：CLAUDE.md導入後

同じチームにCLAUDE.md（3層哲学）を導入した。3つの変化が観察された。

• 出力の収束: どのメンバーがAIエージェントを使っても、同じ判断基準（原理原則と理念）が適用された。アウトプットの方向性が一貫した。
• レビュー負荷の軽減: 品質管理が、すべての出力を詳細にレビューすることから、「哲学に沿っているか？」の一点確認に移行した。レビューコストがN（チームサイズに比例）から1（哲学に比例）に低下した。
• エージェントの自律化: 以前は人間の介入が必要だった未知の状況で、エージェントが思考の型から判断を導出するようになった。タスクごとの指示が不要になった。

図4：Before/After ── 哲学の有無による比較

定量データに関する注記: 本稿執筆時点では、正式な定量計測は実施していない。上述の定性的改善は明確かつ一貫している。Philosophy Scrum（セクション5.4）に基づく計測手法を、後続の発表で予定している。

7. 考察

7.1 既存アプローチに対するポジショニング

現在のアプローチはHowで競争している。Philosophy as CodeはWhyで競争する。これはHowが重要でないという主張ではない ── ハーネス・プロンプト・検索システムは必要なインフラである。主張は、Howには天井があり、その天井は未知に遭遇したまさにその時に到達するということだ。Whyは、特定のルールが存在しない状況でも機能する導出メカニズムを提供することで、その天井を突破する。

7.2 形骸化の罠

あらゆる手法は形骸化に脆弱である ── 形式は保存されるが機能が腐敗するプロセス。スクラムは進捗報告会議に形骸化する。TDDは実装後テストに形骸化する。コードレビューはゴム印承認に形骸化する。

エージェントハーネスも同じリスクに直面する。哲学的基盤なしに制御構造を定義するハーネスは、時間とともに、チームが理解せずに従うテンプレートの集合になる。ハーネスはエージェントの振る舞いを統治するが、なぜエージェントがそう振る舞うべきかを誰も説明できなくなる。

Philosophy as Codeも形骸化から免れない。だからこそPhilosophy Scrumが存在する ── 双方向検証が、哲学を現実に対して継続的にテストし、機能しなくなったときに更新することを保証する。

7.3 限界

1. 単一コンテキストでの検証。 Philosophy as Codeは単一の組織コンテキストでテストされている。異なる業界・チーム規模・AI成熟度での組織横断的な検証が必要である。
2. 定量計測の不在。 正式な定量指標はまだ収集されていない。Philosophy Scrum内で定義された計測手法（準拠率、違反パターン、哲学進化頻度）を適用し、後続の研究で報告する。
3. 手動検証への依存。 現在の実装はプレーンテキストファイルと人間による検証に依存している。哲学準拠の継続的モニタリングを自動化するツールを開発中である。
4. 実装のLLM依存性。 3層哲学（原理原則・理念・思考の型）自体は特定のLLMに依存しない。しかし本稿で示した実装 ── .claude/rules/によるコンテキスト注入制御、.claude/skills/によるドメイン知識モジュール化 ── はAnthropicのClaude Codeのハーネス機構に基づいている。他のLLMベースのエージェントで同等の哲学駆動型統治を実現するには、そのエージェントの仕組みに応じた制御層（ルールの注入タイミング制御、知識の遅延読み込み等）を設計する必要がある。哲学の構造は移植可能だが、ハーネスの実装は移植先に合わせて再設計される。

8. 結論

ハーネスは必要だ。しかし哲学なきハーネスは形骸化する ── ちょうど哲学なきスクラムが会議の集合になり、哲学なきTDDが実装後に書かれるテストになるように。

Philosophy as Codeは構造的な逆転を提案する。「どう」の前に「なぜ」を定義せよ。哲学を原理原則・理念・思考の型の3層構造として実装せよ。CLAUDE.mdとしてコード化せよ。Philosophy Scrumで検証せよ。計測せよ。進化させよ。

CLAUDE.mdファイルは実装であると同時に哲学であり、テストである。それはBitcoinホワイトペーパーとBitcoinソースコードの両方に相当する ── システムの記述であると同時に、システムそのものである。

「考えるな、従え」── その時代は終わった。
「考えろ、そして水になれ。」

参考文献

1. Pan, L., Zou, L., Guo, S., Ni, J., & Zheng, H.-T. (2026). Natural-Language Agent Harnesses. arXiv preprint arXiv:2603.25723. arxiv.org/abs/2603.25723
2. Yao, S., Zhao, J., Yu, D., Du, N., Shafran, I., Narasimhan, K., & Cao, Y. (2023). ReAct: Synergizing Reasoning and Acting in Language Models. ICLR 2023. arxiv.org/abs/2210.03629
3. Shinn, N., Cassano, F., Gopinath, A., Shakkottai, K., Labash, A., & Karpas, E. (2023). Reflexion: Language Agents with Verbal Reinforcement Learning. NeurIPS 2023. arxiv.org/abs/2303.11366
4. Khattab, O., Singhvi, A., Maheshwari, P., Zhang, Z., Santhanam, K., Vardhamanan, S., Haq, S., Sharma, A., Joshi, T. T., Mober, H., et al. (2023). DSPy: Compiling Declarative Language Model Calls into Self-Improving Pipelines. arXiv preprint arXiv:2310.03714. arxiv.org/abs/2310.03714