はじめに
本記事で述べる「哲学をAIの設計原理にする」という考え方を、実際のプロジェクトですぐに試せるフォーマットとして、CLAUDE.md（Claude AIへの哲学の渡し方を定義したテンプレート）を記事末尾で公開している。哲学の三層構造をどうコードに落とし込むのか、具体的な型を知りたい方は先にそちらを見ていただいても構わない。
よりプロジェクトで活用したい方は以下からお問い合わせください。
▶ B-LAND株式会社へのお問い合わせ📩 support@b-land.co
AIに仕事をさせる上で、少なくとも自分が辿り着いた答えは、精緻なメソッドでも業務マニュアルでもなく「哲学」だった。
これは理論から導いた結論ではない。実際にAIをプロジェクトに導入し、使い込み、AIが返してきた見当違いなアウトプットを何度も画面の前で頭を抱えながら修正する中で辿り着いた実感だ。そしてその答えの原点は、ビジネス書でも技術書でもなく、自分が長年取り組んできた武術──ブルース・リーが創始したJeet Kune Do（截拳道）──の中にあった。
「思った通りのアウトプットが出ない」「想定外のケースに対応できない」。AI導入の現場で絶えず聞こえてくるこの声の根本は、AIの性能ではなく、AIへの指示の設計思想そのものにある。
「メソッド」と「哲学」は違う
AIに「Aの場合はBを出力」「Cの場合はDを出力」と定義する。一見合理的に見えるが、ビジネスの現場でも開発の現場でも、想定していなかったEやFが必ず発生する。ルールを100個用意しても、101個目の未知のケースには対応できない。
ここで区別すべきなのが「メソッド」と「哲学」の違いだ。
メソッドは具体的な手順や処理方法の指定であり、いわば絶対値・定数にあたる。「このフォーマットで出力しろ」「この手順で処理しろ」「返品にはこのテンプレートで返答しろ」。再現性は高いが応用が利かない。
哲学は抽象度が高いが、全体の統率に長ける。思考や思想としては具体化されているが、指示系統としては抽象的に機能する。未知の状況にも一貫した判断を導く力がある。
AIに渡すべきはルールの集合ではなく、「何を最も大切にするか」「どういう思想で判断するか」という上位概念だった。思想を与えれば、AIはその思想に沿って自ら思考する。この構造が機能して初めて、想定の外にある未知の問題にも一貫したアウトプットが得られる。
「哲学」を因数分解する
では、ここでいう「哲学」とは具体的に何を指すのか。この言葉を曖昧なまま使い続けると、それ自体がメソッドのない精神論になってしまう。哲学を因数分解すると、三つの層が見えてくる。
哲学 ＝ 原理原則 × 理念（意念） × 思考の型
第一層：原理原則──「世界はこう動いている」という構造の認識。武術でいえば「力は中心線に集約される」「作用には反作用がある」。個人の意志とは無関係に存在する法則であり、誰がやっても変わらない。ビジネスでいえば「顧客は期待と現実の差分で満足度を判断する」「信頼の構築は漸進的だが、崩壊は一瞬で起きる」といった、市場や人間行動の不変の構造がこれにあたる。
第二層：理念（意念）──「自分は何を最も大切にするか」という価値判断。同じ原理原則を知っていても、何を優先するかは人や組織によって異なる。ブルース・リーは「適応」を最上位に置いた。ある企業は「顧客との長期関係」を置き、別の企業は「スピード」を置く。この層が、同じ原理原則から異なる判断を生み出す分岐点になる。
第三層：思考の型──「原理原則と理念をどう接続して判断に至るか」というプロセス。Jeet Kune Do（截拳道）でいう「構え」に近い。構えそのものは技ではないが、構えがなければどんな技も繰り出せない。「まず全体を見る」「逆から考える」「一度手放して再構成する」──こうした思考の回路が、原理と理念を実際の判断に変換する。
この三層が揃って初めて、「哲学」はAIに渡せるものになる。原理原則だけでは教科書にすぎず、理念だけではスローガンにすぎない。思考の型がなければ、理論は知っていても体が動かない武術家と同じだ。
AIの設計に当てはめれば、原理原則は「AIの基本的な振る舞いの制約」、理念は「この組織がAIに何を最優先させるか」、思考の型は「どういうプロセスで判断させるか」に対応する。三つの層を意識的に設計することで、「哲学で動かすAI」は抽象論ではなく実装可能な設計思想になる。
「Be water」── 武術が教えてくれた型の限界
この因数分解に辿り着いた原点は、武術の稽古にあり、Jeet Kune Do（截拳道）の創始者ブルース・リーには有名な言葉がある。
"Be water, my friend."
水はコップに入ればコップの形になり、瓶に入れば瓶の形になる。何にでも可変し、適応する。ブルース・リーが説いたのは、固定された型（メソッド）ではなく、あらゆる状況に適応する原理（哲学）の重要性だった。
しかし「水になれ」には、もう一つ深い層がある。ブルース・リーの哲学の根底には道教の思想がある。その中核にあるのが「無為自然」──物事をこうあれと無理やり定義するのではなく、河川をつくり、水がどう流れるかは自然に任せるという考え方だ。川の形は設計する。しかし、水の流れはコントロールしない。
これはAIの設計思想として極めて示唆的だ。AIに哲学を渡すとは、水の流れ方を一つ一つ指定することではない。川の形──つまり原理原則と理念と思考の型──を設計した上で、その中でAIがどう判断するかはAI自身に委ねる。コントロールするのではなく、方向性を与えて自走させる。「Be water」の本質は、「適応せよ」であると同時に「支配するな」なのだ。
武術において、意念や思想が打撃を変えることを自分は体験している。同じパンチでも、「相手を倒す」と考えて打つのと、「拳の先にある壁を突き抜ける」と考えて打つのとでは、拳の重さがまるで違う。手順は同じなのに、意念一つで身体の出力が変わる。同じ技術を同じ手順で教えても、メソッドだけでは継承に至らないことが多い。しかし「なぜその動きをするのか」という原理原則を伝えると、学ぶ側は未知の状況にも自ら対応できるようになる──つまり「コップの形に変わること」ができるようになる。
これはAIの問題と構造的に同じだ。カスタマーサポートのルールをどれだけ列挙しても、テンプレートの隙間に落ちるケースは必ず出てくる。しかし「顧客の信頼回復を最優先にする」という判断原則を与えれば、想定外の状況でもAIは一貫した対応を生成できる。マニュアルだけで動く組織が想定外に弱いように、ルールだけで動くAIも想定外に弱い。渡すべきは手順書ではなく哲学なのだ。
実証 ── TDDの「思想」を渡したら、AIが自走した
※本セクションはソフトウェア開発の実例を扱うため、やや技術寄りの内容となっている。技術者でない方は、「哲学を渡したら実際にどうなったか」という結論部分を中心にお読みいただきたい。
ここまでの話は抽象的に聞こえるかもしれない。そこで、実際のプロジェクトで「哲学を渡す」ことの効果が明確に現れた事例を紹介する。
まずTDDについて簡単に触れておく。TDD（Test-Driven Development：テスト駆動開発）とは、ソフトウェア開発の手法の一つだ。通常の開発では「まずプログラムを書き、その後にテストで動作を確認する」という順序で進める。TDDはこれを逆転させる。「まず"こう動くべきだ"というテスト（合格基準）を先に書き、そのテストに合格するようにプログラムを書く」というアプローチだ。料理に例えるなら、通常は「とりあえず作ってから味見する」のに対し、TDDは「先に完成形の味を決めてから、その味になるように調理する」という進め方にあたる。
ただし、この手法は理想的でありながら、人間の開発現場では浸透しにくい。理由は二つある。一つは時間がかかること。ビジネスの現場では「まず動くものを見せろ」と求められるため、テストを先に書く工程は後回しにされがちだ。もう一つは、TDDの性質上、開発が「エラーを出すこと」から始まる点だ。まだ何も動くものがない状態で画面が真っ赤なエラーメッセージで埋まる。上司が後ろを通りかかれば「何も進んでないのか」と見える。そこから一つずつ赤を消していく作業を、成果物ゼロの状態で黙々と続けなければならない。
しかしAIにとっては、この構造がむしろ理想的に機能する。AIはエラーの山を見ても動揺しない。「正しい状態の定義」が先に与えられていれば、そこに向かって淡々と実装を収束させていく。人間が苦手とする「ゴールだけが明確で、道中はエラーだらけ」という状態は、AIにとっては最も得意な問題構造だ。TDDは、人間よりもAIの方が向いている開発手法だと言える。
あるプロジェクトで、このTDDの思想をベースにAIへ実装を任せたことがある。結果として、AIはほぼ自動で、大きなエラーもなく、全体の実装を滞りなく完遂した。
重要なのは、AIに渡したのがTDDの「手順」ではなく「思想」だったという点だ。
「テストを先に書き、実装し、リファクタリングする」──この手順だけを渡すのであれば、それはメソッドにすぎない。多くの現場でTDDが形骸化するのは、この手続きの層だけを導入するからだ。しかしTDDの本質は手順ではなく、「正しさの定義を先に決め、それに向かって実装を収束させる」という思考様式にある。何を作るかではなく、何が正しい状態かを先に考える。この判断原理をAIに渡した。
先に述べた哲学の因数分解に当てはめると、こうなる。
原理原則：正しさの基準が曖昧なまま作ると、必ず手戻りが起きる。これは人間の開発でもAIの開発でも変わらない不変の構造だ。
理念：「正しさを先に定義する」ことを最優先にする。速さでも網羅性でもなく、まず「何が正しい状態か」を明確にすることを最上位の価値として置く。
思考の型：テストという形式で正しさを具体化し、そこに到達することだけを考えて実装を進める。逸脱したら立ち止まり、テストに立ち返る。
この三層をAIに渡したとき、AIは個別の実装判断を自律的に行いながらも、全体としてブレない方向性を維持し続けた。想定外のケースに遭遇しても、「正しさの定義」に立ち返り、テストが通る道を自ら見つけ出した。人間が横から修正を入れる場面がほとんどなかった。まさに、ルールの隙間を哲学が埋めた瞬間だった。
もしTDDの「手順」だけを渡していたら──「まずテストを書け、次に実装しろ、最後にリファクタリングしろ」というメソッドだけを渡していたら──AIはテストの形式的な記述に囚われ、テストを通すことが目的化し、全体の設計は早い段階で破綻していただろう。
TDDは、メソッドとして使えばメソッドだが、思想として渡せば哲学になる。そしてAIが自走できるかどうかの分岐点は、まさにそこにあった。
無形のものをどう継承するか
TDDの事例は、哲学が「今この瞬間のAI」を機能させることを示していた。ではもう一歩先を考えたい。その哲学を、時間を超えてどう残すのか。
人類は歴史の中で、知を継承するために様々な方法を編み出してきた。唄に意味を込め、石板に文字を刻んだ。では、マニュアル化できない無形の判断基準──いわゆる暗黙知──はどう残すのか。
経営学者の野中郁次郎は、組織の知識を「形式知」と「暗黙知」に分類した。マニュアル化できる形式知（メソッド）に対し、言語化しきれない判断原理である暗黙知こそが組織の本質的な競争力だと論じた。
その暗黙知を継承する最も有効なフォーマットが「哲学」だ。
ブルース・リーは1973年に亡くなったが、「Be water」という哲学はJeet Kune Do（截拳道）の実践者たちの中に50年以上生き続けている。形式知として文書化されなくても、意念として残り続ける。マニュアルは陳腐化するが、哲学は生き残る。
AI時代において、プロンプトやコード、使用するモデルは頻繁に変わる。しかし「何を判断させたいのか」「どういう思想で動かすのか」という哲学がチームや組織に共有されていれば、ツールが変わっても一貫した方向性を保てる。無形の集団に意思疎通と継承を行う上で、哲学というフォーマットが最も適している。
この考え方は、自分だけが辿り着いたものではない。宮本武蔵は『五輪書』で「一つの道を知れば万事に通ず」と述べた。AnthropicはConstitutional AIでルールではなく原則をAIに内在化させるアプローチを取っている。ナシーム・ニコラス・タレブは『反脆弱性』で、固定的ルールへの依存がシステムを脆くすると論じた。異なる分野──武術、AI開発、複雑系科学──で独立に到達された同じ結論。これ自体が、この原理の普遍性を物語っている。
この国が抱える静かな矛盾
ここまで「哲学を持て」と書いてきた。しかし、この提言が日本社会においてどれほど困難なことかも、同時に書かなければ誠実ではない。
この国の教育と労働の仕組みは、長い時間をかけて「考えないこと」を最適解にしてきた。正解を速く正確に再現する者が評価され、問いを立てる者は煙たがられる。会議で手を挙げて意見を言えば、周囲が目を伏せて沈黙する。上司の方針に「それ、本当に正しいですか」と口にすれば、翌日から仕事が回ってこなくなる。自分の意思や主義主張を持つことは、多くの職場において美徳ではなくリスクだった。
その結果、日本の労働市場は「優秀な作業者」を大量に生み出すことには成功した。指示されたことを正確にこなす。マニュアル通りに動く。決められたルールの中で最大効率を出す。それは確かに、ある時代においては競争力だった。
ブルース・リーはこうも言っている。
「人間はパターン化された思考と行動によって、成長をやめるものだ」
この言葉は武術について語られたものだが、今の日本の労働環境にそのまま当てはまる。パターンの中で最適化を続けた結果、パターンの外に出る力を失った。そしてAIは、まさにその「パターンの中で正確に動く」能力において、人間を凌駕しつつある。
皮肉なことに、AIを最も効果的に活用できる人材像は、この国が長年かけて排除してきた人材像と重なる。自分の頭で考え、原理原則から判断を下し、前例のない状況にも自らの思想に基づいて対応できる人間。つまり「哲学を持つ人間」だ。
マニュアル通りに動く人間の仕事はAIに置き換わる。しかし、AIにどんな哲学を与えるかを設計できる人間は、AIには置き換えられない。ルールを実行する側から、ルールの上位にある思想を定義する側へ。AI時代に求められるのは、この不可逆な移行だ。
これは個人の話だけではない。組織の話でもある。「言われたことだけやれ」という文化の企業は、AIに渡す哲学を持たない。なぜなら、そもそも哲学を必要としない仕組みで回してきたからだ。AIの導入が進むほど、その空洞が露呈する。
哲学の不在は、AI以前には見えにくかった。人間がルールの隙間を暗黙のうちに埋めていたからだ。しかしAIはその隙間を埋めない。哲学がなければ、AIは黙ったまま処理を止めるか、誰も頼んでいない回答を延々と生成し続けるだけだ。
AIという鏡は、組織が本当は何を考えていたのか──あるいは何も考えていなかったのか──を、残酷なまでに映し出す。
水になれ
ブルース・リーは型を徹底的に学んだ上で、型を捨てた。そして「水になれ」という哲学に到達した。
それは「何も考えるな」という意味ではない。原理原則を骨とし、理念を血とし、思考の型を筋肉として身体に刻んだ上で、状況に応じて自在に形を変えろという意味だ。
AIに仕事を任せるとき、我々はつい「具体的に、正確に」指示を出そうとする。経営者はマニュアルの精度を上げようとし、開発者はルールの網羅性を高めようとする。それ自体は間違いではない。しかし、ルールを積み重ねるだけのアプローチには構造的な限界がある。
必要なのは、そのルールの上位にある思想──なぜそうするのか、何を最も大切にするのか──を三つの層で明確にし、それをAIの設計思想に落とし込むことだ。
そしてそれは同時に、この国の働き方に対する問い直しでもある。哲学を持つことがリスクだった時代は、AIの登場によって終わりを迎えつつある。哲学を持たないことこそが、これからの最大のリスクになる。水のように変化に適応するAIは、哲学からしか生まれない。しかし、哲学だけでは空を掴むようなものだ。メソッドだけでは器のない水であり、哲学だけでは流れのない川にすぎない。武術には陰陽という思想がある。攻撃と防御、剛と柔、動と静──一見対立するものが、実は互いを生かし合って初めて機能するという考え方だ。哲学とメソッドもまた同じ構造にある。哲学が方向を与え、メソッドが現実に接地させる。どちらかを捨てるのではない。両方を抱えたまま、自らの中にある「型」を一度壊すところから始まる。
Philosophy as Code 〜哲学をコードにする── CLAUDE.mdの公開
本記事で述べた「哲学の三層構造」を、AIの設計原理として実際に機能させるためのテンプレートを公開する。CLAUDE.md(Claude AI)は、原理原則・理念・思考の型をAIに渡すためのフォーマットであり、自分のプロジェクトに合わせて書き換えることでそのまま使える。
▶ CLAUDE.mdテンプレート
哲学は囲い込めない。囲い込んだ瞬間に型になって死ぬ。だからこのテンプレートは全公開する。まずは自分で試してほしい。
ただし、テンプレートを埋められることと、自社の暗黙知を哲学として引き出せることは別の能力だ。
「三層構造はわかった。しかし、自分たちの原理原則が何なのかを言葉にしようとすると手が止まる」 「書いてみたが、チームに共有しても誰もピンと来ていない」 「理念は立派に掲げてある。でも、現場の判断と繋がっていない」 「AIに哲学を渡したいが、そもそも自分たちの哲学が何なのかわからない」
一つでも当てはまるなら、それは哲学が不在なのではなく、まだ言語化されていないだけだ。答えはすでにチームの中にある。我々B-LANDは、その暗黙知を問いによって引き出し、三層構造に落とし込むコーチングを行っている。
▶ B-LAND株式会社へのお問い合わせ📩 support@b-land.co
哲学 × AI駆動開発支援（Claude Code） 自社開発で培った哲学的アプローチとClaude Codeを活用したAI駆動開発のノウハウを、外部のお客様にも提供しています。技術選定から設計思想まで「なぜ作るのか」を問うことで、表層的なDXではなく本質的な変革を支援します。