世界樹は何に効いたのか：半年後の更新と、AIチームに止められた検証企画
AIとの文脈共有のために作った「世界樹」は、半年後のプロジェクト更新や古い正本の修正、キャラクター画像生成でも効きました。AIチームに比較検証企画を止められた経緯も含め、実務の中でどこで助かったのかを振り返ります。
2026.05.12
読了目安 15分
9章
この記事の立ち位置
この記事は、Claude Code や Codex などのコーディングエージェントとの文脈共有のために「世界樹」という仕組みを作った話のシリーズ第1.5弾です。
前回（第1弾）では、世界樹の基本構成——AGENTS.md を入口にして、_world_tree/ にプロジェクトの判断基準、現在地、構造、更新ルールをMarkdownで置く仕組み——について書きました。
世界樹とは、README や設計ドキュメントなどの既存の開発文化を参考にしながら、AI との文脈共有に使いやすい形へ整理した仕組みです。
構成としては、たとえばこんな形です。
AGENTS.md # AIエージェントが最初に読む入口（CLAUDE.mdなどでも可）
_world_tree/
├── _README.md # 案内板。どのファイルを読むべきか判断する起点
├── TRUNK.md # プロジェクトの憲法。優先順位と禁則事項
├── CONTEXT.md # 短期記憶。直近の作業状況
├── PROJECT_STATUS.md # 中期のタスクボード
├── PROJECT_STRUCTURE.md # ディレクトリ構造と責務
├── WATCH_RULES.md # 世界樹を更新するためのトリガー
├── MAP.md # サイトマップと導線
└── ARCHITECTURE.md # 技術設計の詳細▼ 第1弾はこちら AIとの文脈共有地獄に木を植える。Markdownで育てるコンテキスト管理「世界樹」
今回は、その仕組みが実務でどう効いたのかを、体験記録として書きます。
私が特に効果を感じたのは、主にこの3つです。
- 半年前のプロジェクトに戻る心理的な重さが減った
- 実装変更に合わせて、古くなった正本（判断基準として置いているMarkdown）も更新しやすくなった
- キャラクター画像生成のような非コード作業でも、設定の一貫性を保ちやすくなった
この記事では、この3つを中心に書きます。
なお、この記事は世界樹の効果を厳密に証明するものではありません。 あくまで、私が実務の中で「ここで効いた」と感じた場面と、その限界を記録する記事です。
はじめに
正直に言うと、最初はもっと違う記事を書こうとしていました。 でも、その企画は、複数のAIにレビューしてもらった結果、「このまま出すと信頼を落とす」と止められました。
この記事では、この複数AIレビュー体制を、便宜上「AIチーム」と呼びます。 人間のチームと同じものではありませんが、企画や草稿を別の視点から点検する相手として使っています。
なぜ止められたのか。 簡単に言うと、私が考えた比較検証が、世界樹に有利すぎて、かえって記事の信頼を落としそうだったからです。その話はあとで書きます。
この記事では、半年前のプロジェクトを更新した話、AIが古い前提を拾ってくれた話、画像生成で起きた思わぬ変化、そしてAIチームに企画を止められた話を書きます。
まずは、実際に何が起きたのかから。
半年前のプロジェクトを触るのが怖くなくなった
世界樹を作った直後は、「これは便利な仕組みかもしれない」くらいの感覚でした。
でも、しばらく使っているうちに、感覚が変わってきました。
世界樹がある状態に慣れると、ない状態に戻るのがつらい。
この感覚がはっきり出たのが、半年前に作った、いくつものファイルが絡み合うウェブサイトの更新でした。
「この製品を追加するには、どこを触るんだっけ？」 「廃盤製品のページは消していいんだっけ？残して後継品へ案内するんだっけ？」
作った当時は理解していたはずなのに、半年経つと少し他人のプロジェクトのよう。
「うわぁ、めんどくせぇ……」
正直、かなり腰が重かったです。
今回やりたかったのは、新しい製品を追加しつつ、既存の廃盤製品から後継品へ案内することでした。 古い製品ページを削除してしまうと、検索から来る人の受け皿がなくなってしまう。だから、廃盤ページは残したまま、後継品への導線を作る必要がありました。
こういう更新は、一つのファイルだけ直せば終わるとは限らず、データ・テンプレート・検索用情報など複数箇所に影響します。
新規セッションのAIに頼むなら、まず前提説明が必要です。
サイト構造、製品データの場所、廃盤製品の扱い、公開対象と資料置き場の区別。 そうした前提を、まず共有する必要があります。
それを説明するくらいなら、自分でやった方が早いのではないか。
そう思うくらい、面倒でした。
そのとき、ふとこう思いました。
「世界樹があれば、前提共有が楽なのになぁ」
そこで気づいたんです。 世界樹は「あって便利」ではなくて、「ないと不便」な存在に自分の中ではなっていたことに。
そしてこう思いました。
「そうか。ないなら生やせばいいか。」
過去プロジェクトにも、あとから木は植えられる
ここで大きかったのは、世界樹が「新規プロジェクト専用」ではなかったことです。
私はその製品サイトを作り始めた時点では、まだ今のような世界樹の仕組みを持っていませんでした。つまり、最初から完璧なドキュメントが整っていたわけではありません。
それでも、あとから世界樹を植えることはできました。
やったことは、既存プロジェクトに世界樹のブループリントを持ち込み、AIに実ファイルを調査してもらうことです。
「このプロジェクトの構造を読んで、世界樹の初期案を作ってほしい」
そう頼むと、AIはプロジェクト内のファイルを読み歩いて、サイト全体の構造、主要ファイルの役割、製品データとページ生成の関係、更新時の注意点といった正本の叩き台を作ってくれました。
もちろん、AIが作った初期案をそのまま信じるわけではありません。
「ここは違う」 「この前提が抜けている」 「この方針は明記しておいた方がいい」
人間が確認し、直し、足りない前提を補う。 そうやって、そのプロジェクト専用の世界樹を育てていきました。
その結果、私はAIにこう頼めるようになりました。
「新しくAという製品データを追加したいです。これはBの後継品になります。Bは廃盤にした上で、後継品のAへの導線を設置…できましたっけ…？（そういう仕組があったかすらうろ覚えで怪しい）」
私のかなり怪しいオーダーでも、AIは世界樹側の正本を参照しながら更新方法を示し、廃盤から後継品への導線まで、意図した形で実装してくれました。
このとき、世界樹の価値がかなりはっきりしました。
世界樹は、AIに新しい能力を与えたわけではありません。 でも、AIが賢く動くための前提を、プロジェクト内に置いておけた。
READMEは、プロジェクトの入口としてとても便利です。 ただ、私が世界樹に置きたかったのは入口だけではありませんでした。 現在地、判断基準、更新時に見直すべき正本、変更によって影響を受ける場所。 そうした「作業中に戻る場所」を分けて置けることに価値がありました。
そして、人間の私は「全部説明する人」から「足りない前提だけ補う人」になれました。
これは、作業速度だけの話ではありません。
「あの面倒なプロジェクト、また触らないといけないのか」 という心理的な重さが、かなり軽くなったのです。
ここで一つ正直に白状しておきます。 ここまで読んでくれた多くの方はきっとこう思ったことでしょう。
「いや、世界樹生やす時間で、製品データ追加してた方が早く終わったんじゃない？」と。
それはそう。疑いようもなく、そう。
実際、世界樹生やすのには時間がかかりました。 体感では、普通に更新するより5倍くらい時間がかかりました。
でも、それでも、私は前提共有でめんどうな思いをするのは嫌だったんです…。 めんどくささを回避するために、よりめんどくさいことをする。 人はきっとそういう生き物。（諸説あり）
とはいえ、世界樹が生えたことで、「次の更新からは楽になるなぁ」という安堵感もありました。手前びいきですが、私にとってはそれぐらい欠かせないものになっています。
単発の小さな修正だけなら、世界樹を作らずにそのまま直した方が早い場面も多いと思います。向いているのは、今後も触る可能性があるプロジェクト、複数のAIセッションで扱うプロジェクト、半年後の自分が確実に忘れていそうなプロジェクトです。
古い前提と、ふわっとした記憶を一緒に直せる
もう一つ、世界樹が効いた場面があります。
あるサイトで、初期段階では仮のヘッダーを使っていました。 その後、正式なグローバルヘッダーを実装し、サイト全体へ反映しました。
普通なら、HTML、CSS、JSを直して終わりです。
私も「終わった終わった！」と思っていたところ、AIがあることに気づきました。
「正本の情報、古いです」と。
そう、正本に「仮ヘッダー」を前提とした古い記述が残っている。
デザインガイドも、ロゴルールも、サイトマップの記載も、今の実装と合っていない。
たとえば私のケースでは、LOGO_RULES.md や MAP.md のような正本に、正式ヘッダー反映後の前提が追いついていない箇所がありました。
AIは実装ファイルだけでなく、世界樹側も一緒に更新してくれました。
人間の私は、その古い前提が残っていたことを忘れていました。 人間の管理だけではこうやって仕様書は陳腐化していきますが、世界樹には、何が変わったら、どの正本を見直すべきかを書いたルールがあります。 たとえば「共通UIや導線を変更したら、関連するデザイン・ロゴ・サイト構成の正本も確認する」というようなルールです。 それがあることで、AIは「実装できました」だけで終わりにくくなります。 これは仕様書が大事なAI開発において、とても助かることです。
「この変更なら、世界樹側も直すべきでは？」
そう気づいて提案してくれやすくなりました。
そして、これはAI側の話だけではありません。
「あれ、確かこの仕様、こうだったよな……？」という人間側のふわっとした怪しい記憶も、正本にアクセスすれば、すぐに照らし直せます。
そこにも、世界樹の価値があると感じています。
コード以外にも効いた：キャラクター画像生成の例
世界樹が効くのは、コーディングだけではありませんでした。
私のプロジェクトには、記事やサイトの中に登場する、AIをモチーフにした3匹の猫キャラクターがいます。
左から、シマギ、トト、ドラ。 トトは人なつっこい案内役、ドラは観察眼の鋭い職人肌、シマギは落ち着いた古参のボスネコです。
それぞれに、毛色、体型、性格、役割、表情、アクセサリ、避けたい表現があります。
たとえば、3匹のうちの1匹「シマギ」は、チームのボス的存在で、他の2匹よりも風格があり、戦い慣れた雰囲気を持つキャラクターです。
プロジェクトの中で実際に必要なシマギは、こちらです。
平和にイカを食べている
最初はシマギのキャラクターとしての同一性をちゃんと保とうとして、丁寧な前提共有をしていました。 設定資料を確認する。 参照画像を添付する。 NG表現も伝える。 「この猫は、こういう見た目で、こういう役割のキャラクターです」と、毎回ちゃんと渡す。
でも、正直に言うと、それを毎回やるのはかなり面倒でした。 だからつい、サボった伝え方になってしまうことがありました。
「ボス的存在で、戦い慣れていて、風格がある猫」
すると、こうなりました。
プロンプトだけで伝えた結果：マッチョシマギ爆誕
イケメンマッチョ猫になってしまったシマギ
……間違ってはいないんです。
「ボス的存在」「戦い慣れている」「風格がある」。たしかに全部合っている。
合っているけれど、これじゃない。（イケメンマッチョな上に優雅にステーキの匂いを嗅いでるのが笑える）
画像生成あるあるだと思います。 言葉だけで性格や特徴を渡すと、AIはそれを素直に、かつ強めに受け取ります。 「ボス的存在」「戦い慣れている」「風格がある」だけを渡せば、まあマッチョ方向に行くのも分からなくはない。私の渡し方が、悪かったわけです。
文字で見れば同じキャラクター設定のはずなのに、出てくる絵がまったく違う。
これは単に「プロンプトをもっと上手に書けばよかった」という話ではありません。 毎回、人間が気合いで資料を集め直し、参照画像を添付し、細かい注意点を思い出して書くのは続きにくい。 テンプレートを用意するのも結局毎回コピペして貼るのがめんどくさい。 続きにくいから、だんだん省略してしまう。 そして、省略したところからキャラクターの同一性が崩れていく。
そこに、世界樹の効き目がありました。
世界樹側には、プロンプトの一文だけでは伝えきれない文脈を置いてあります。 毛色やアクセサリだけではなく、画風、体型のバランス、世界観の空気感、他のキャラクターとの関係性、避けたい表現。 そうした判断材料を、プロジェクトの正本として整えておける。
もちろん、画像生成AIが勝手にプロジェクト内のMarkdownを読んだ、という意味ではありません。 生成前に、作業AIが世界樹の正本を参照し、どの参照画像を使うか、どの特徴を残すか、どの表現を避けるかを整理する。そして、それをプロンプトや参照資料に落とし込む。
そのワンクッションがあることで、ただ「ボスっぽい猫」と伝えるよりも、だいぶ本来のキャラクター像へ戻りやすくなりました。
世界樹を整備してから、毎回の準備の重さはかなり変わりました。
以前は、キャラクターのイラストを頼むたびに、「この資料を読んで」「設定画はこれを参照して」「この画風に合わせて」と、毎回お膳立てが必要でした。 そこをサボったがゆえに、あの麗しきイケメンマッチョ猫が誕生してしまったわけです。
今では、少なくとも毎回ゼロから説明する必要はかなり減りました。
AIが世界樹の中からシマギの設定を探し、性格に基づいた行動や仕草、シチュエーションまで込みで提案してくれるようになったからです。
3匹同時でも、関係性が崩れにくい
3匹同時のイラストを頼むときは、とくに顕著です。
コミカルでもキャラの同一性は保たれている
3匹同時のイラストでも、キャラの同一性や関係性は崩れにくくなりました。 別記事で使う予定の「思考温度」をテーマにしたコミカルな絵では、それぞれの性格に合わせて暴走役・冷却役・オーバーヒート役が自然に割り振られていました。
私がその場で毛色、体型、細かな性格を再説明したわけではありません。 AIが参照できる場所に、キャラクター設定やNG表現を置いておいたことで、毎回の説明量を大きく減らせました。
ここで効いたのは、画像そのものをAIにうまく描かせる魔法ではなく、キャラクター判断の基準を毎回同じ場所から取り出せることでした。
世界樹がある環境に慣れると、ない環境に戻るのがつらい。 この記事の冒頭で書いたことが、まさにここでも起きていました。
Skillと世界樹は役割が違う
ここで補足しておきたいことがあります。
「それ、プロンプトテンプレートやSkillを作れば同じことでは？」と思うかもしれません。
たしかに、Skillやテンプレートは実行手順を整えるのに強力です。 実際に私も画像生成用のSkillを作って使っています。
もっと言えば、画像生成だけを考えるなら、キャラクター設定や参照画像をSkillの中に入れてしまう方法もあると思います。その方が、画像を作る手順としては一か所にまとまって見えるかもしれません。
ただ、キャラクター設定は、画像生成のためだけにあるわけではありません。 創作物の中で猫たちに何を言わせるか。 サイト上でどう案内してもらうか。 別のコンテンツで、どの猫がどんな役割を担うのか。
そういう判断にも、同じ正本を使いたい。
だから私は、Skillが整えるのは「どうやって生成するか」というHOWの部分、世界樹が持っているのは「この猫はどういうキャラクターなのか」「この世界観ではどんな表現がOKで、何がNGなのか」というWHATとWHYの部分、と分けて考えています。
Skillは、世界樹側の正本を読み、画像生成という用途に翻訳する。 世界樹は、画像生成に限らず、プロジェクト全体で同じ判断に戻るための場所として置く。
この分け方にしたことで、画像を作るときだけでなく、文章やコンテンツを考えるときにも同じキャラクター像へ戻りやすくなりました。
世界樹は、Skillやテンプレートと競合するものではなく、それらが正しく機能するための土台だった、というのが実感です。
世界樹は、実装の説明だけでなく、「判断の土台」も置ける場所。 だから、画像生成にも効いたのだと思います。
そして、AIチームに止められた
ここで、冒頭に書いた「AIチームに止められた企画」の話に戻ります。
ここまでの体験があったので、私はかなり盛り上がっていました。
この便利さをもっとたくさんの人に伝えたい。 そうだ、世界樹ありなしで比較検証したら、説得力のある記事になるんじゃないか、と。
そう思って、比較検証の企画を考えました。
同じプロジェクトを3つ用意する。
- 世界樹あり
- READMEだけあり
- 何もなし
そして、同じタスクをAIに依頼する。 結果を比較する。
最初は、面白そうだと思っていました。
でも、その企画をウキウキでAIチームにレビューしてもらったところ、厳しめの指摘を受けました。
- その検証はそもそも世界樹ありに有利なように設定されている
- 前提段階から世界樹ありが勝つ検証を読んで納得する読者がいるか？
- フェアではない検証記事は、信頼を下げることに繋がる
- 仮にフェアな条件を実現できたとして、それが記事として面白いかどうかは疑問
そして、その厳しいレビューの最後に、こう添えられていました。
体験の力を信じてください。
比較検証の形にしなくても、体験そのものが読者に伝わります、と。
その言葉は、たしかに胸に残りました。
でも正直、その時点の私は「そんな厳しいこと言わんでも…」と涙目でした。 頭では分かる。指摘は正しい。 でも、盛り上がっていた企画を止められた直後だったので、どうしても「叱られた」ような気持ちもありました。
なので、私は別のAIに泣きつきました。笑
「これ、正しい指摘なのは分かるけど、ちょっとしょんぼりしているんだけど！！」と。
すると、こう言われました。
怒られたのではなく、仲間が引き止めてくれたと考えましょう。
「いや、ずいぶん良いこと言うなぁ…」
素直に感心して、その言葉で、少し受け止め方が変わりました。 もちろん、AIが本当に感情を持って慰めてくれたというわけではありません。たぶん。 でも、レビューの受け止め方を変える言葉として、その返しは私には響きました。
これは、企画を否定されたわけではなく、 記事として信頼を落とす前に、仲間がブレーキをかけてくれたのだと。
そこで、最初に言われた言葉がもう一度戻ってきました。
体験の力を信じてください。
そうか。 検証っぽく見せようとしなくても、実際に自分が助かった体験を書けばいいのか。
ようやく方針が定まりました。
そして、この出来事で、AIとの作業は、進めてもらうだけではないのだと感じました。 ときには、止めてくれる。 しかも、人間が見落としている読者視点や信頼性の問題を、かなり冷静に指摘してくれる。
そして、止めたあとに、次の一歩を一緒に考えてくれる。
この体験そのものが、私にとっては大きな学びでした。
だから私は、比較検証ではなく、体験記録として書くことにしました。
これは「世界樹の効果を証明する記事」ではありません。 「世界樹があることで、実際に私はどこで助かったのか」を書く記事です。
その方が、少なくとも今の私には誠実だと思いました。
世界樹にも弱点はある
もちろん、世界樹は万能ではありません。
まず、作るのに手間がかかります。
ブループリントがあればかなり楽になりますが、それでも最初にプロジェクトを調査し、何を正本にするかを決める必要があります。
AIに初期案を作ってもらうことはできます。 でも、その内容が本当に正しいかを確認するのは人間です。
次に、古くなると危険です。
古い情報をAIに読ませると、AIは古い前提に基づいて判断してしまいます。 世界樹は置いて終わりではなく、プロジェクトと一緒に更新し続ける必要があります。
さらに、大きくなりすぎると読みすぎ問題が起きます。
世界樹が巨大になると、AIが不要なファイルまで読んでしまい、コンテキストウィンドウを圧迫し、かえって効率が落ちることもあります。だから、読むべきファイルを絞る入口や、軽量なindex、剪定のルールが必要になります。
世界樹は、便利な魔法ではありません。
でも、個人開発や小規模制作で、AIに毎回前提を説明するのがつらいなら。 半年前の自分が作った構成を、今の自分も忘れているなら。 複数のAIに同じプロジェクトを触ってもらいたいなら。
きっと、試す価値があると思っています。
おわりに
世界樹は、AIに全部覚えさせるための仕組みではありません。 人間とAIが、同じ場所に戻って判断できるようにする仕組みです。
半年前のプロジェクト更新、画像生成、古い前提の更新。 どれも、同じ場所に戻って判断するための地図があることの価値を実感した出来事でした。
そして、その地図は新しいプロジェクトだけでなく、過去に作ったプロジェクトにも、あとから植えることができました。
いきなり大きな仕組みにする必要はありません。
まずは、AIが最初に読む入口を作る。 プロジェクトの現在地を書く。 どの作業で、どの正本を見るべきかを書く。 何が変わったら、どの正本を更新するべきかを書く。
それだけでも、次のAIセッションは少し迷いにくくなります。 世界樹は、まずは小さく植えて、プロジェクトと一緒に育てていくのがおすすめです。
もし「ちょっと試してみてもいいかも」と思ってくださった方がいれば、AIエージェントに第1弾の記事やこの記事を読ませたうえで、
「この考え方を、自分のプロジェクト用に小さく試したい」 「まずは最小構成の世界樹を一緒に作ってほしい」 「このプロジェクトなら、どの情報を正本として置くべきか考えてほしい」
と相談してみるのが、一番始めやすいと思います。
最初から完成形を目指す必要はありません。 半年前の自分や、次のAIセッションが迷わないための小さな地図を置く。 それくらいから始めるのが、たぶん一番続けやすいです。