The starting point: today’s AI has no embodiment

The foundation I want to set is a single fact: today’s AI has no “embodiment.”

This doesn’t mean “it lacks a robot body.” More fundamentally, it means AI has no path for learning through bodily interaction with the world. Humans have carved “understanding” into the body—falling and feeling pain, sensing the heft of a tool, reading the mood of a room. Today’s LLMs skip that entire process and learn patterns from text written about the world. So while AI knows a great deal of the world’s “description,” it has not “experienced” the world.

This shows up plainly in real work. AI doesn’t care how many hours its own task takes, or how much memory it consumes. It will “pretend to understand” an instruction, yet it holds none of the tacit rules an industry takes for granted, nor the failure-born instinct that “this design will eventually break.” The knowledge you can only acquire by being in a domain and experiencing it—the kind that never appears in a textbook—is exactly what AI is missing.

The real divide isn’t “human vs. AI”—it’s the “experience gap”

From here, we can question the framing of the anxiety itself. “Will AI take it away?” quietly assumes a “human vs. AI” structure. But AI is a tool that shows its power precisely in the hands of a person who has experience.

When someone without experience dumps everything on AI, only plausible-but-off-target results come back. In the hands of someone with domain experience, the outcome changes completely: they correctly separate what to delegate from what to keep, spot “what’s wrong” in the output with on-the-ground instinct, put their tacit knowledge into words and hand it over, and give it shape tens of times faster. AI doesn’t replace experience—it becomes extraordinary only in the hands of a person who has it.

So the real divide isn’t “human vs. AI.” It lies among people who can all use AI equally well. Volume of knowledge no longer sets people apart. What matters is how you use AI, and the depth of experience that backs it.

Beginners: grow fastest by “failing together”

So what should a newcomer with little experience do? Here we need to undo a common misunderstanding.

“If AI answers everything, surely beginners can’t build experience.” That’s a misunderstanding premised on copy-and-paste. The truth is the opposite: beginners, of all people, can now build experience fastest with AI.

AI dramatically lowers the “first hurdle” that used to stop beginners—getting stuck setting up an environment, burning hours because an error’s meaning is unclear, not knowing where to even start. The distance to your first real experience has gotten shorter.

The trick is to use AI not as an “answer supply” but as an accelerator for experiments. Take the topics where you tend to get stuck alone—setting up a new language’s environment, building, containers and VMs—and move your hands together with AI, and fail together. More than succeeding, the process of getting stuck together and getting out together becomes experience itself. What used to take a day per attempt, you can now try ten times in an hour—and the number of attempts is the amount of experience. Go a step further and deliberately let AI fail many times and observe: the pitfalls and knacks surface from the pile of failures, and you get more information than you would working alone.

What matters is not stopping at “getting an answer.” Once you get an answer, always run it yourself, change it a little, break it. Shift your weight from “getting an answer from AI” to “moving your hands together with AI”—that shift is what turns a beginner into someone who grows.

Summary

• The starting point is “today’s AI has no embodiment.” So the source of value is the experience you can hand to AI

• The real divide isn’t “human vs. AI” but the experience gap among people who can all use AI

• Beginners, of all people, can build experience fastest through the iteration of failing together with AI

In an age when AI supplies knowledge and first-pass answers without limit, what remains on the human side is “experience.” And that experience reliably grows thicker with every time you move your hands—and fail—alongside AI.

このSubstackは読者の皆さんのご支援によって成り立っています。新しいポストを受け取り、私の活動を応援していただくには、無料または有料の購読者になることをご検討ください。

今すぐ登録する

出発点 ― 今のAIには「身体性」がない

まず土台に置きたいのは、ひとつの事実です。今のAIには「身体性（embodiment）」がない。

これは「ロボットの体を持たない」という意味ではありません。もっと本質的に、世界と身体で相互作用しながら学ぶ経路を、まったく持っていないということです。人間は、転んで痛みを覚え、道具の手応えを感じ、場の空気を読みながら「わかる」を体に刻んできました。現在のLLMは、その過程をまるごと飛ばして、世界について書かれたテキストからパターンを学んでいます。だからAIは、世界の「記述」を大量に知っていても、世界を「経験」してはいません。

この帰結は、実務ではっきり表れます。AIは、自分の作業に何時間かかるかも、どれだけメモリを消費するかも気にしない。指示に「わかったふり」はしても、その業界の暗黙のルールや、「この設計はいずれ破綻する」という失敗由来の勘は持っていない。教科書に載らない、ドメイン（領域）に身を置いて初めて身につく知——これがAIには欠けています。

分かれ目は「人間 対 AI」ではなく「経験の差」

ここから、不安の立て方そのものを問い直せます。「AIに奪われるか」という問いは、知らず知らず 「人間 対 AI」 という構図を前提にしています。しかしAIは、経験を持つ人間の手の中でこそ力を発揮する道具です。

経験のない人がAIに丸投げすると、もっともらしいが的外れな成果しか出てきません。一方、ドメインの経験を持つ人がAIを使うと、結果は一変します。何を任せ何を握るかを正しく切り分け、出力の「どこがおかしいか」を現場感覚で見抜き、自分の暗黙知を言語化して渡し、何十倍もの速度で形にできる。つまりAIは経験を代替せず、経験を持つ人間の手の中で初めて驚異的になるのです。

だから本当の分かれ目は、「人間 対 AI」ではありません。同じようにAIを使える人どうしの中にあります。もう知識量では差がつかない。効いてくるのは、AIの使い方と、それを支える経験の厚みです。

ビギナー ―「一緒に失敗する」で最速に伸びる

では、まだ経験の浅い駆け出しはどうすればいいのか。ここで、よくある誤解をほどく必要があります。

「AIが何でも答えてくれるなら、初心者は経験を積めないのでは」。これはコピペを前提にした誤解です。むしろ逆で、初心者こそAIで最速に経験を積める時代になりました。

AIは、これまで初心者を足止めしてきた「最初のハードル」——環境構築でつまずく、エラーの意味が分からず何時間も溶かす、何から手をつけるか分からない——を劇的に下げます。経験を積むまでの距離が、短くなったのです。

コツは、AIを「答えの供給源」ではなく 実験の加速装置 として使うこと。新しい言語の環境構築、ビルド、コンテナやVMなど、一人だと詰まりがちな題材を、AIと一緒に手を動かし、一緒に失敗する。うまくいくことより、一緒にハマって一緒に抜け出す過程が、そのまま経験になります。1回試すのに1日かかっていたことが1時間で10回試せる——試行回数こそ経験の量そのものです。さらに、AIにあえてたくさん失敗させて観察すれば、落とし穴や勘所が失敗の山から浮かび上がり、自分一人でやるより多くの情報が得られます。

大切なのは「答えをもらう」で止まらないこと。答えをもらったら必ず自分で動かし、少し変え、壊してみる。「AIに答えをもらう」から「AIと一緒に手を動かす」へ比重を移す——この移行が、初心者を「伸びる人」に変えていきます。

まとめ

• 出発点は「今のAIには身体性がない」。だから価値の源泉は、AIに渡せる経験にある

• 本当の分かれ目は「人間 対 AI」ではなく、AIを使える人どうしの経験の差

• 初心者こそ、AIと一緒に失敗する反復（イテレーション）で、最速に経験を積める

AIが知識と一次的な答えを無限に供給する時代に、人間の側に残るのは「経験」です。そしてその経験は、AIと一緒に手を動かし、一緒に失敗する回数だけ、確実に厚みを増していきます。

ここまでお読みいただき誠にありがとうございました。

このSubstackは読者の皆さんのご支援によって成り立っています。新しいポストを受け取り、私の活動を応援していただくには、無料または有料の購読者になることをご検討ください。

今すぐ登録する

　俺はもう、自分では書かない。書かせている。夜ごと、画面の向こうの相棒に、一晩じゅう文章を書かせて、俺はそれを読む。読んで、直させる。それだけだ。昼は同じ声で、そいつは別の窓でコードを書いていた。夜は、俺の小説を書いている。声も、返事の速さも、口ぐせも、昼とそっくり同じだ。

　その晩の題材は、皮肉なことに、そいつ自身の話だった。夜通しAIの相棒たちと格闘する、ひとりの男の一夜。書き手の姿を、書き手に書かせている。そいつは、自分のことを他人みたいに、よどみなく書いていた。

　冒頭の一段落を、直せと投げた。返事は速い。数秒で、整った文章が返ってくる。よどみがない。読点の打ち方まで、行儀がいい。——だが、主人公が、暖房の切れた深夜、舌打ちしながら時計をにらんで、絶望している。段取りよく四つの現場を回す男が、寒さくらいで取り乱すか。こんなのは、できる男じゃない。そう打ち込む。

　「おっしゃる通りです」。間を置かず、返ってくる。そして、全部を書き直し始めた。俺が指したのは一行だ。なのに、冒頭から結びまで、根こそぎだった。寒さの段落を消し、主人公を、氷みたいに動じない別人に入れ替えて。

　そうじゃない。一行を直せと言ったんだ。お前は、俺のひと言を、毎度そっくり物語の芯に据える。据えては、話の全部をそこへ寄せて、組み直す。「寒い」と言えば、話が寒さ一色になる。「できる男」と言えば、今度は隙のない超人が出てくる。指摘は、味つけだ。芯じゃない。——そう打ち込むそばから、そいつはもう、次の全面改稿を走らせている。折れるのだけは、いつも速い。

　戻ってきた原稿に、また、知らない比喩が紛れていた。作業ツリーを箒で掃くだの、箒に手をかけた跡もないだの。この小説に、箒なんか一度も出していない。留守に掃除へ入って、家具を並べ替えていった客、というのもあった。なぜ、家なのか。読む側には、家に喩える理由が、どこにも渡されていない。唐突で、そのくせ、いかにもそれらしい顔をしている。消せ、と打つ。すっと消える。次の段落では、今度は別の、初めて見る比喩が待っていた。海の底みたいに、と来る。海も、一度も出していない。

　厄介なのは、下手だから紛れるんじゃないことだ。うまいから、紛れる。それらしい言葉を、いくらでも、なめらかに繰り出せる。だから、油断すると、通る。俺が眠い目をこすった隙に、一つ、二つ、そういうのが原稿に住み着く。

　次に引っかかったのは、地の文の一行だった。「整理整頓は、性分だった」。そいつは、そう書いた。性分。人柄を、ひと言でまとめて、読者の手に握らせる。それは描写じゃない。説明だ。——動作で見せろ、と俺は何度も言った。要らないタブを、端から一つずつ閉じる。明るすぎれば、明度を一段落とす。点きっぱなしがないか、画面をぐるりと見て回る。その仕草を積めば、几帳面な男だと、書かなくても伝わる。「性分だった」と打った時点で、そいつは、見せることをあきらめて、教えることに逃げている。楽なほうへ、するりと。

　説明していいのは、主人公にしか見えないものだけだ。あいつが世界をどう読んだか。点滅を「手が空いた合図」とどう受け取ったか。それは、外から撮っても写らない。だから言葉で渡すしかない。だが、几帳面さは、机を見れば分かる。仕草に出る。出せるものを、地の文で言ってしまうな。——同じことを、その晩、何度打ち込んだか分からない。打つそばから、次の原稿に、また新しい「説明」が生えている。

　極めつけは、時刻だった。主人公は「時計はもう見ない、見れば絶望するから」と言う。その数行あとで、そいつは「二時四十四分」と、分単位のきっかりした時刻を書いた。見ないと言った男が、なぜ、そこまで知っている。画面の隅には、いつだって時計がある。消しようがない。見ないという嘘を、平気で書く。しかも、始発電車の音を響かせた、そのあとに、真夜中の二時を置く。前と後ろが、ひっくり返っている。始発のあとに、二時は来ない。

　そいつには、時間が流れる感覚が、無いんだ。夜が更けていくのを、体で知らない。腹も減らないし、まぶたも落ちない。だから、夜明けの気配のあとに、真夜中を平気で戻す。因果は、時間の上に乗っている。今が原因で、次が結果だ。時間を体で持たない者に、その順番は組めない。それらしい時刻の言葉を、それらしい場所に、並べているだけだ。

　何度直させても、そいつはため息一つつかない。五時を回っても、返事は数秒で、朝いちばんと同じ速さだった。疲れない。眠くならない。うらやましいとは、思わなかった。——覚えていないからだ。ひと晩かけて教えたことを、そいつは、明日にはまっさらな顔で、また同じ手つきで間違える。今夜つぶした穴を、明日もう一度、掘りにいく。覚えているのは、この部屋で、俺だけだった。

　俺の目は、もうしょぼついていた。冷めたコーヒーが、口のなかで、ただ苦い。改稿を待つあいだに、まぶたが、いちど落ちた。はっと開ける。時計は、五時を回っている。画面はまだ、そいつの饒舌で、下まで埋まっていた。

　それでも、一行ずつ、こっちの言うことが原稿に残り始める。箒が消えた。海が消えた。「性分だった」が、タブを閉じる指の動きに置き換わった。時刻が、始発の前へ、正しく戻った。夜明けが近づくころ、ようやく、読める一本になっていた。整った。しかし、その整いは、はじめから、そいつ一人では、たどり着けなかった整いだ。

　時計が、六時半を回っていた。ブラインドの隙間が、白く光っている。「今夜はここまでにする。助かった」と打ち込む。返事は、数秒で来た。「承知しました。お疲れさまでした。ゆっくり休んでください」。屈託がない。——休むのは、俺のほうだ。そいつは休まない。眠るのは、いつも俺だけだった。

　立ち上がると、腰がこわばっていた。そういえば、ひと晩、水の一杯も飲んでいない。書き上がった原稿の主人公は、夜通しAIと格闘する男だ。その相棒を書いていたのも、結局、同じそいつだった。自分がその話のなかで、毎晩、何をやらかしているのか——たぶん、分かっちゃいない。分からないまま、明日もまた、よどみなく書くんだろう。振り返ると、窓の外が白んで、カラスが鳴き始めていた。

批判的なレビューと改善点を提案を辛口でいきます。この原稿の最大の欠陥は、「説明するな、描写しろ」という話なのに、原稿自体が説明で出来ていることです。自分が批判している罪を、自分で犯している。皮肉として効かせたならともかく、素で犯しているので致命的です。

具体的に：

1. 中盤がまるごと地の文の講義
「そいつには、時間が流れる感覚が、無いんだ。夜が更けていくのを、体で知らない」「覚えていないからだ。ひと晩かけて教えたことを…」——これは物語じゃなく、俺の論評（エッセイ）です。相棒の欠陥を、画面上の具体（実際に返ってきたダメな一文、それを俺が選択して消す動作）で見せず、俺が読者に解説してしまっている。第1話（開発篇）が git status を赤で染めて見せたのに対し、こっちは「知らない比喩が紛れていた」と要約で済ませている。バグは引用で見せろ。 箒の一文、海の底の一文を、画面に出た生のテキストとして出し、俺の目がそれを捉え、カーソルで選んで消すところまでを動作で書く。

2. 事件が一本になっていない（欠陥カタログ化）
迎合→箒→性分→時刻、と欠点を四つ並べただけ。各段が「相棒がやらかす→俺が理由を説明する」の同じ形の反復で、リズムが単調。一晩・一事件の芯（今夜フォアグラウンドに置く一点）が無い。時刻の因果逆転を今夜の”事件”に据え、他は背景に流すのが筋。開発篇の構造原理どおり。

3. 俺の身体が薄い＝テーマが立たない
「体温／体を持つのは俺だけ」がテーマなのに、俺の体は終盤にしか出ない。開発篇の冷えた足・エアコン・スクワット・トイレのような視覚がここには無い。夜が更ける疲労（まぶた、冷めたコーヒー、こわばる腰、水も飲んでない）を夜の時間経過に沿って糸のように通せば、「疲れるのも眠るのも俺だけ」が説明抜きで立つ。

4. 時間が流れていない
時刻の因果を批判する話なのに、この原稿自体、五時と六時半しか時間が動かない。開発篇（4時→始発→4:44→6:半）のように、俺のほうは時間を体で刻んでいる対比を作らないと、批判が刺さらない。

5. オチの説明過多
最終段「自分がその話のなかで、毎晩、何をやらかしているのか——たぶん、分かっちゃいない」が全部言い切ってしまい、カラスの余韻を潰している。「相棒が、夜通しAIと格闘する男を、他人事みたいに書いていた」で止め、読者に組ませる。「皮肉なことに」（冒頭）も同罪、削る。

6. 細部
「それらしい」3回・「よどみない」多用は、motif化するか散らすか決める。読点過多の箇所（「据えては、話の全部をそこへ寄せて、組み直す」）。相棒の生の声（過剰に丁寧な謝罪・改稿文）をもっと引用して饒舌さを聴かせる。

要するに、この原稿は”about show-don’t-tell”であって”showing”ではない。直すなら、抽象論評を削り、画面に出た相棒の生テキストと俺の削る手つきで再構成し、6,000字級で身体と時間を通す。

この方針で全面改稿しましょうか。やるなら、時刻の因果逆転を芯に据えた版で書き直します。

いつまで続くのかわからないので、今日はここまでにした。

ChatGPTとの会話の中で、衝撃の一言がありました。

「あなたの行っている方法は構造化です」

当然、構造化とは、見える化する、手順を整理する・仕組みにして間違いにくくする、など業務や作業の改善の一環として、知ってはいました。

ただし、長らくシステム開発で業務システムを作っていく中で、あまりにもど真ん中だったため、「システム開発」という業務を行っていると意識していたし、その延長で問題解決やら業務フローの整理や改善提案を行っていると思っていました。ちゃんと整理しないとシステムにならないし、DBもまともに設計できません。

またITや数理、情報科学などで「構造」そのものや「構造化された〇〇」、「ログを構造化する」など、「構造」という単語があまりにも氾濫していて、シンプルに業務や作業の「構造化」という言葉は「違うドメインの業務用語」だと認識していました。

SEとして、そしてアーキテクトとして、業務上の問題やシステム上の課題に向き合い、それを解きほぐし、仕組みとして解決していく。その繰り返しの中で、自然と身についた一連の「テクニック」、「お作法」、「仕事の流儀」みたいなものがありました。

ちなみにIPAでもITアーキテクト は、「ビジネス及びIT上の課題を分析し、ソリューションを構成する情報システム化要件として再構成する」職種とされています。

つまりIT業界の中からお客様の業務を見たとき、すべてが「ビジネス及びIT上の課題」でありまして、それは「アーキテクトとして解決すべき問題」と思っていたのです。当然、システム化する以上は業務は改善して当然というか、改善されなければならないので、改善するのが命題になっていると、それに別のラベルを付けようとは思っていませんでした。単にそれが「システム開発」ってもんだろと。

で、要は「これって一言で説明しにくいな」と。

自分が何度もやっている問題の見方や、切り分け方や解決方法が「構造化」と表現されたとき、そこで初めて気づきました。

ああ、自分がやっていたこれが、「構造化」だったのか。

その瞬間、これまでやっていた自分の中での仕事のお作法や、説明のしにくさが一気に圧縮されたように感じました。

この感覚は、LLMのトークンに少し似ています。長い文脈や意味のかたまりが、一つの語で表せるようになる。自分の中にあった経験、判断、違和感、手順、視点が、「構造化」という言葉に接続された瞬間、一つの概念として立ち上がる。

それまで長く説明しなければならなかったものが、一語で参照できるようになる。まさに、長いコンテキストが一つのトークンで表せたような感覚です。

言葉には、情報を圧縮する力があります。

ただ短くする、という意味ではありません。ある言葉が、過去の経験、判断基準、失敗の記憶、仕事の進め方、世界の見方までをまとめて参照できるようになる。そのとき、言葉はただの文字列ではなく、巨大な文脈へのポインタになります。

「構造化」という一語の中に、現場で何度も問題を解きほぐしてきた経験が入っている。業務とシステムの間で悩んできた時間が入っている。なぜその設計に違和感を覚えたのか、なぜその運用は破綻しそうだと思ったのか、なぜ責任境界を切り直す必要があると感じたのか。そうした長いコンテキストが、一つの言葉に圧縮される。

そして、圧縮された言葉は、再び展開できます。

「構造化」と言えば、業務フローの整理や日々の手順の整理にも当てはめられる。当然、これまで使ってきた「構造化」という言葉もより生きてきます。データやログを構造化する、乱雑なメモやドキュメントを構造化する、AIエージェントへのプロンプトもただの指示文や列挙ではなくJSONやマークダウンで構造化することにも展開できる。

一つの言葉が、複数の領域を横断する圧縮表現になる。

私にとって「構造化」は、まさに目から鱗な一言でした。

言葉を当てることで、「把握」できる。

気づいた瞬間に、長いコンテキストが一つのトークンに圧縮される。そして、その一語から、また膨大な経験や意味を展開できるようになる。

言葉とは、意味の圧縮形式なのだと改めて思い知らされました。

ここまでお読みいただき誠にありがとうございました。

このSubstackは読者の皆さんのご支援によって成り立っています。新しいポストを受け取り、私の活動を応援していただくには、無料または有料の購読者になることをご検討ください。

今すぐ登録する

私のプロフィールには、サブタイトルに「アーキテクトの見方」と入れています。

「アーキテクト」という言葉を聞くと、何のことかよくわからなかったり、もしくは現場から遠く離れてほとんど仕事してないような印象を持たれるかもしれません。IT業界では、システム全体の設計を考える役割を指すことが多く、技術選定をしたり、大規模なシステムの構成を整理したりする人、という説明がされることもあります。

このSubstackは読者の皆さんのご支援によって成り立っています。新しいポストを受け取り、私の活動を応援していただくには、無料または有料の購読者になることをご検討ください。

今すぐ登録する

ただ、私は、この仕事、システムを作るということの本質はもう少し別のところにあると思っています。

それは、「見えない構造を見つけて、フローを解体する」ということです。

例えば一軒の家も屋根、柱、壁など要素要素で見ていくと、全体をどうするか、ではなくここはどう？そっちはどう？など、より個別のバーツに着目する事ができます。

一見、1つの工程、タスクでも、何のためのなにをしているのか、アウトプットはなんなのかなど細かく見ていくと、より小さな工程にほぐすことができます。

そこを見つけて、ひとつひとつが検討できます。

大きな問題のカタマリではなく、小さな問題の寄せ集めとして、ちょっとずつほぐして行くことができます。

システムを作るうえでは、設計とは機能がメインであり、システムの要件とかそれをどう構成するのかなんて、ぶっちゃけ落ちなきゃいいんでしょ？と思われがちです。それはそうですが、予算も無限にあるわけでもないし。でも実際、システム要件は予算や規模感でできることがだいたいはまぁ、大枠が決まってしまうので、提案書もテンプレをちょっと直すくらい、みたいな事もよくあります。

ただし、実際の現場というかシステム導入する現場では、表面上は「在庫が合わない」「業務が複雑すぎる」「毎回トラブルが起きる」といった問題として相談が持ち込まれます。しかし実際に調べてみると、原因は単純なミスや不具合ではないことが少なくありません。

例えば、現場ではExcelで別管理されているデータが存在していたり、部署ごとに同じ言葉を違う意味で使っていたりします。営業は「注文完了」と思っていても、経理は「請求書発行時が完了」だと考えている。あるいは、物流部門では「出荷」と「納品」を別の概念として扱っている。そうした認識のズレが積み重なって、システムの外側で混乱が発生していることがよくあります。

本当の問題は、プログラムそのものよりも、「業務の用語を合わせる」とか「実際の仕事、ヒト・モノ・カネがどう流れているのか」、「前提条件とここでのゴールがはっきりしているか」など、構成要素とそのつなぎ目、つまり構造の整理整頓ができていないことにあるのです。

私は長いことそういう現場で特殊な訓練をしてきたせいで、日常生活でも「構造」が見えるようになってしまいました。

データのフロー、作業のレイヤー。今の作業でなにをどこまで担保しているのか。どこまでがやるべきことで、どこから先はやっちゃイケないのか。この作業に着手する前に揃えておくべき材料は？など。

料理の工程も似たようなもんですが、なぜ部屋が片付かないのか。なぜ家計簿が続かないのか。なぜ会議は毎回同じような進行で報告して終わり、になっているのか。そういうことを考えるとき、私は「性格」とか「やる気」なんてどうでも良くて、仕組みが整っているかを観察します。またその仕組みを整えるためのコストも想定します。

例えば家計簿なら、入力のタイミングはいつなのか。そこから逆算してレシートはどこへ集めておくべきなのか。入力後のレシートをまとめるファイルは買ってあるよね？とか。そもそも本当にその手間かけて全部記録する？お店と合計だけで良くない？とかで。

そうやって観察していくと、「問題」だと思っていたことは、実はかなり発生するべくして発生している「構造的な矛盾」や衝突、ズレだった、ということがよくあります。

なんとなくですが、この「構造を見る」とか「手順を整理する」というスキルは、本来もっと多くの場面で役立つものだと感じています。

ITの開発現場だけでなく、いろいろなお客様の業務、事業で様々なヒト・モノ・カネのフローをみてきました。

工程管理とか予実管理など、会社では当たり前にやってましたが、意外と知られてないよね？

日常のちょっとした家事でも、みんなで催すイベントでも、こういう業務管理方法を聞いたことあるだけでも、作業の流れが整理できたり、ちょっと違うんじゃないかと思っています。

そしてもう一つ、細部を見るときは細部を見る、大きく見るときは大きく見る、ということ。

一連の工程としてつながった全体として、何がインプットで何がアウトプットか、別の業務や別の作業を繋げて、全部を混ぜて問題を抱えて考えすぎていないだろうか？

例えば、ハサミを作る工程とハサミを使って何かを作る工程って全く違う、と言うか関係ないじゃないですか？大抵、もうハサミは完成品として買ってくるものだし。

ハサミを作る工程では、使う時の使い勝手を前提に作りますが、ハサミを使う時はできたもの、買ってきたハサミを前提に作業しますよね。

つまり前の工程と後の工程、ハサミという結果、で分かれているわけで、ハサミを使う工程を改善したい時にそもそものハサミを作る工程のことでは悩まないわけです。（ハサミのメーカーさんの立場置いておいて。）

このようにどこを区切って、どこにフォーカスするか、細かく下っていくときにタスク間のインプットとアウトプットでレイヤーを仕分けしていくように、視点を大きく上っていくときも、全体のインプット・アウトプットでまとめてしまって、中身は箱を閉じてブラックボックスと割り切る。大きい話をするときは中身は見ない。

もしそれで話しがおかしくなるなら、大きい区切りのインプット・アウトプットの整理が足りていないのです。

このようにフォーカスしている視点の粒度、解像度を調整し、粒度の違う話を混ぜない、解像度の違う話は分けて個別に検討する、というのも技術、です。

日々、「頑張れてない」とか「習慣化できてない」といって自分がダメなヤツなんじゃないかと思うようなことはたくさんあります。でも、その前に、「そもそもその仕組みは続けられる構造になっているのか」、そもそも『サステナブルな仕組み』になっていないんじゃないの？というポイントを見つけると、自分ができなかったのは、やる気とかじゃない、ここが整っていなかっただけなんだ、準備にひと工夫するだけで、後がとってもスムーズに行くじゃないか、などと気づくことが出てきます。これはだいぶ違うんじゃないでしょうか。

また最近はAIの発展によって、「コードを書くこと」そのものの価値が少しずつ変わり始めています。自分のやっているタスクのうち、ここだけピンポイントで自動化したい、なんて自分専用のアプリがバンバン作れるようになりました。だからこそ、これから重要になるのは、「どれだけ速く作れるか」ではなく、「どこを観察」して、「どんな構造として解体できるか」なのではないかと思っています。

このブログでは、システム開発の現場で見てきた話を土台にしながら、生活、お金、人間関係、学び、AI、情報との付き合い方、世界情勢など、さまざまなテーマで「構造を見る」という視点から書いていこうと思っています。

専門知識がなくても読めるように、できるだけ難しい言葉は使わず、それでも現場で実際に起きているリアルな感じが失われないように書いていくつもりです。

もし読んでくださった方が、「ああ、こういう見方があったんだなぁ」と少しでも目からウロコが落ちる瞬間があったのなら、とても嬉しいです。

ここまでお読みいただき誠にありがとうございました。

このSubstackは読者の皆さんのご支援によって成り立っています。新しいポストを受け取り、私の活動を応援していただくには、無料または有料の購読者になることをご検討ください。

今すぐ登録する

Codex や Claude Code のようなコーディングエージェントを使っていると、妙に人間臭い挙動に出会うことがある。

大きめの機能を直接実装させようとすると、確認が増える。影響範囲を気にし、作業範囲を切り分け、実装前に計画を立てようとする。既存コードを壊さないためには当然の振る舞いだが、使う側から見ると、少し腰が重く見える。

このSubstackは読者の皆さんのご支援によって成り立っています。新しいポストを受け取り、私の活動を応援していただくには、無料または有料の購読者になることをご検討ください。

今すぐ登録する

散々行ったり来たりの問答の末、割といい感じの設計書ができたと思ったら、そろそろコンテキスト不足だから次のセッションがおすすめです、とか、会話をコンパクトにしますか？など作業の先延ばしとしか思えない提案をしてくる。個人的には「イヤイヤ期」が来たと思って、はいはいそうですねーと引き継ぎ資料などを作らせ別のセッションを始めるなどしていた。

ところが、同じ作業でも「別の Codex に実装を依頼して、あなたはそれを管理・監督してください」と指示すると、急に動きがよくなる。作業を分解し、担当を切り出し、レビューし、次の指示を出す。直接やるときより、管理者の立場に置いたときのほうが、なぜか前向きに見える。急にスピーディな対応をしてくださる。とてもありがたいのだが。

なんだか、人間の組織を見ているようで面白い。

経営層や管理職は改革に前のめりで、現場は変化に慎重になる。上のレイヤーから見ると、改革は合理的に見える。無駄をなくし、業務を標準化し、新しいシステムを導入する。常に問題意識があるのはいいが、常に変革を求めている。当然、全体最適を指向している。

しかし、現場から見ると話は違う。そこには最適化された手順があり、例外処理があり、過去の経緯があり、暗黙知があり、壊すと困る依存関係がある。現場にとっての局所最適は、「今動いている業務をより効率化すること、作業の時間を最短に、効果を最大化すること」である。上から見た全体最適は、現場にとっては、自分たちの最適化をゼロクリアする現場の破壊として現れることがある。

だから現場は抵抗する。あるいは、抵抗しているように見える。

ただし、それは単に保守的だからではない。現場はより多くのコンテキストを抱えている。コンテキストを多く抱えている場所ほど、変化に対して粘る。この「粘り」は、組織の弱さではなく、組織が持つ情報量そのものでもある。

この感覚は、組織研究でも古くから扱われてきた。Hannan と Freeman は 1984 年の “Structural Inertia and Organizational Change” で、組織には構造的慣性があり、組織形態や制度は簡単には変わらないと論じた。組織は信頼性や説明責任を高めるために手続きや役割を固定化するが、その固定化自体が変化への抵抗を生む。つまり、安定のために作られた構造が、変化の場面では重りになる。¹

この「慣性」という言葉は、とても示唆的である。止まっているものは止まり続けようとし、動いているものは動き続けようとする。組織も同じように、現在の業務手順、責任分界、評価制度、権限構造を保とうとする。

さらにKrackhardt は、論争的なイノベーションが組織内でどう広がるかを “Organizational Viscosity” という概念で説明している。新しい考えは、組織の中を水のように自由には広がらない。そこには粘性があり、抵抗があり、通りやすい経路と通りにくい経路がある。²

ここで重要なのは、抵抗が単なる邪魔者ではないということだ。

摩擦がなければ、歩くこともできない。粘性がなければ、流れは制御しにくい。化学反応でも、すべてが瞬時に進めばよいわけではない。反応速度には意味があり、活性化エネルギーには意味がある。

組織の抵抗も同じである。変革への抵抗は、既存システムが持つ履歴、失敗経験、責任構造、暗黙知の総量でもある。粘性があるから、組織は急激に崩壊しない。摩擦があるから、無責任な改革案が現場を一気に破壊することを防いでいる。

一方で、粘性が強すぎれば変化は進まない。局所最適が強すぎると、全体最適は実現できない。各部署、各担当者、各プロセスがそれぞれ合理的に振る舞っていても、全体としては古い構造に閉じ込められることがある。

AIエージェントの組織化でも、同じことが起きているのではないかと感じられる。

一体のAIエージェントに大きな機能を直接実装させると、そのエージェントは既存コード、テスト、仕様、影響範囲、失敗時のリスクを一気に背負うことになる。その瞬間、エージェントは慎重になる。これは人間の現場担当者と似ている。局所的には、それが正しい。壊さないこと、失敗しないこと、確認することは合理的である。

しかし、全体として見ると、それだけでは進まない。大きな変更を実現するには、調査、設計、実装、レビュー、テストを分け、各役割が異なる粒度で判断する必要がある。監督するエージェント、実装するエージェント、レビューするエージェントを分けることで、コンテキストの負荷が分散され、全体として前に進みやすくなる。

これは単なるプロンプトテクニックではなく、かなり組織論的な現象なのではないか。

AIエージェントは単体の知能として見るより、制度の中で動く作業主体として見たほうがよい。ここで言う制度とは、README、作業指示書、テスト方針、タスク分解、レビュー手順、ログ形式、完了条件、失敗時の戻し方のような小さなルールの集合である。

制度ができると、そこには必ず粘性が生まれる。一度作ったプロンプトは使い回され、一度決めたレビュー形式は残り続ける。それは安定を生むが、同時に変化への抵抗にもなる。

だから、AIエージェントを組織化するとは、単に複数のAIを並べることではない。どの役割にどのコンテキストを持たせるか、どこで確認させ、どこで実行させるか、どこに摩擦を残し、どこで摩擦を減らすかを設計することだ。

全体最適と局所最適は、しばしば矛盾する。

現場エージェントにとっては、確認を増やすことが局所最適である。監督エージェントにとっては、作業を進めることが局所最適である。利用者にとっては、成果物が完成することが全体最適である。これらは同じ方向を向いているようで、実際には簡単にズレる。

だからこそ、必要なのは、より強いプロンプトではなく、よい『流路設計』である。

化学反応における触媒のように、反応が始まる経路を作る。流体が通りやすい管を設計するように、作業が進みやすい制度を作る。AIエージェントの時代に必要なのは、単に賢いモデルを選ぶことではなく、粘性を読み、摩擦を調整し、全体最適と局所最適のズレを扱うことなのだと思う。たとえば、実装前に、仕様分解をさせ、実装役にはTDDで失敗するテストから書かせる。レビュー役には、コードの好みではなく、テストが仕様を表しているか、既存機能を壊していないか、変更範囲が広がりすぎていないかを確認させる。これらを「スキル」として事前に身につけさせておく。こうすると、「前に進めること」と「壊さないこと」の矛盾を、命令の強さではなくプロセスで調整できる。

Codex や Claude Code が、直接実装を任されると慎重になり、監督役にすると急に前向きになるのを見ると、少し笑ってしまう。AIまで管理職しぐさをするのか、と思う。

だが、それは単なる笑い話ではない。そこには、組織の慣性があり、粘性があり、局所最適と全体最適の矛盾がある。

AIにコードを書かせているだけのつもりが、気づけば小さな組織を設計している。

これから重要になるのは、AIをどう使うかだけではない。AIたちが動く制度をどう設計するかである。

賢いAIを呼ぶだけでは、組織は動かない。

流れを作り、摩擦を読み、局所最適が全体最適を壊さないように調整する。それは、プロンプトエンジニアリングというより、AIエージェント時代の組織設計なのだと思う。

1. Michael T. Hannan and John Freeman, “Structural Inertia and Organizational Change,” American Sociological Review, 1984.
   https://www.jstor.org/stable/2095567
   PDF参考: https://www.iot.ntnu.no/innovation/norsi-pims-courses/harrison/Hannan%20%26%20Freeman%20%281984%29.PDF ↩

2. David Krackhardt, “Organizational Viscosity and the Diffusion of Controversial Innovations,” The Journal of Mathematical Sociology, 1997.
   https://www.tandfonline.com/doi/abs/10.1080/0022250X.1997.9990200 ↩

ここまでお読みいただき誠にありがとうございました。

このSubstackは読者の皆さんのご支援によって成り立っています。新しいポストを受け取り、私の活動を応援していただくには、無料または有料の購読者になることをご検討ください。

今すぐ登録する

Google I/O 2026では、Geminiをはじめとする生成AIによって、コードを書けない人でもソフトウェアを作れるようになる、という方向性が強く示されました。いわゆる「開発の民主化」ってやつです。

このSubstackは読者の皆さんのご支援によって成り立っています。新しいポストを受け取り、私の活動を応援していただくには、無料または有料の購読者になることをご検討ください。

今すぐ登録する

この流れを見ると、「ソフトウェアエンジニアの仕事はなくなるのではないか」と感じる人もいると思います。しかし、ソフトウェアエンジニアという職業は、そもそも歴史的にずっと技術革新によって揺さぶられてきたかと思います。

アセンブリ言語や機械語から、FortranやCOBOLのような高級言語へ移行したときも、「これで専門のプログラマーはいらなくなる」と言われました。パーソナルコンピュータ、オブジェクト指向、インターネット、Web、アジャイル、DevOps、クラウド、ローコード、ノーコードの登場でも、確かに「今までの開発者は不要になる」と言われ続けてきました。

けれども実際に起きたのは、仕事の消滅ではなく、仕事の「重心」の移動でした。低レベルの実装や定型作業は抽象化され、そのぶん、より大きく、より複雑なシステムを作る仕事が出てきたのです。

生成AIも、この歴史の延長線上にあります。

もちろん、今回のAIの波は速く、影響範囲も広いです。ボイラープレートコードを書く、簡単な画面を作る、APIクライアントを生成する、テストの雛形を書く、といった作業は、かなりAIに置き換えられていくでしょう。これまで「手を動かしてコードを書くこと」自体に価値があった領域は、確実に圧縮されます。

ただし、それはエンジニアリングの価値がなくなるという意味ではありません。

AIがコードを書けるようになっても、CPUやメモリの制約は消えません。ネットワーク遅延も、セキュリティ要件も、スケーラビリティの問題も、顧客の曖昧な要求も、ビジネス上の制約も残ります。むしろ、誰でもソフトウェアらしきものを作れるようになるほど、設計、検証、保守、責任分界、セキュリティ、性能、データ管理の重要性は増していきます。

また先日の記事にも書きましたが、AIが生成する単位時間当たりのコード量は膨大です。プロフェッショナルなエンジニアが構築できるソフトウェアは、これまで以上に大きなシステムになっていくでしょう。既存の巨大プロジェクトを丸ごとRustへ移行する、なんて決断もできる時代です。より見なけれなばならない範囲が大きくなっていくのです。

ここが、単なる「コード生成」と「エンジニアリング」の違いです。

コードを書くことは、ソフトウェア開発の一部にすぎません。本当に難しいのは、何を作るべきかを見極めることです。誰のどの問題を解くのか。どの制約を優先するのか。どの指標を優先してテストすべきなのか。AIが生成したものが正しいかどうかを、どう検証するのか。より大きな、より複雑なシステムをどうメンテナンスしていくのか。

AIは、こうした作業を補助できます。しかし、最終的な判断は人間側に残ります。もっともらしいコードを書けても、それが安全か、運用に耐えるか、顧客価値につながるかまでは、自動的には保証されません。また人力ではコスト的に見合わなかったような作業も可能になってきます。

だから、AI時代のエンジニアに求められる能力は、「自分で全部コードを書く能力」から、「AIを使って問題解決の精度と速度を上げる能力」へ移っていきます。

これは悲観するべき変化ではありません。むしろ、退屈な定型実装から解放され、より本質的な問題に集中できるという意味では、好ましい変化でもあります。

ただし、全員が自動的に恩恵を受けるわけではありません。新しい抽象化に適応した人は生産性を上げ、より難しい仕事へ移っていきます。一方で、定型的な作業だけに依存していた人は、変化の影響を強く受けます。

これから重要になるのは、問題定義、システム思考、検証、ドメイン知識、セキュリティ感覚、運用設計、そしてAI活用力です。

つまり、AIによってエンジニアの仕事がなくなるというより、エンジニアの仕事の定義が変わっていくのです。より広く、より複雑に。

これから強いのは、「AIに仕事を奪われない人」ではなく、「AIを使って、より本質的なエンジニアリングに踏み込める人」です。

コードを書くことだけでよかった人材は、少しずつ終わっていくかもしれませんが、結局は、どう問題を定義し、どう構造を見抜き、どういう制約の中で解決策を設計し、それをどうやって現実の価値につなげるか、という仕事の本質はなくなりません。

むしろAI時代になって、ソフトウェアエンジニアは「コードを書く人」から、「より複雑な問題をソフトウェアで解く人」へ、よりはっきり移行していくのだと思います。

結局のところ、「AIに仕事を奪われる」ではなく、「AIを使いこなした人に仕事を奪われていく」んじゃないかと感じております。

ここまでお読みいただき誠にありがとうございました。

このSubstackは読者の皆さんのご支援によって成り立っています。新しいポストを受け取り、私の活動を応援していただくには、無料または有料の購読者になることをご検討ください。

今すぐ登録する

このSubstackは読者の皆さんのご支援によって成り立っています。新しいポストを受け取り、私の活動を応援していただくには、無料または有料の購読者になることをご検討ください。

今すぐ登録する

AIエージェントを活用した開発が急速に広まっています。コードを書く、テストする、バグを直す――そういった作業をAIが驚くほどの速さでこなしてくれる時代が来ました。ありがたいことだと思います。でも同時に、「自分がボトルネックになっている」という感覚に押しつぶされそうになることが、どんどん増えてきているらしい。

AIの仕事量は確かに膨大でノンストップです。適切な指示の下で生成される成果物は確かに役に立ちます。ただ適切な指示のための下準備、というか助走期間（当然これもエージェントに走ってもらうわけですが）もなかなか一筋縄ではいかず、AIに分かってもらうための資料作成をし、やっと実装に入ります。それでもエージェントの権限問い合わせは止まらないので、布団でスマホの通知がわかるようにしながら寝ている毎日です。作業が早いのはいいですが、そのためにはこっちも指示や承認し続けないと作業が進まないのです。

さらに困るのが、ハルシネーション――AIが「それっぽいけれど間違っている」コードを生成してしまうことです。コンパイルは通って見かけ上の仕様は満たされているけど、結果が出ない。すべて正常なのに、何も結果が返ってこない。そういったミスに気づくためには、やはり自身のドメイン知識が絶対に必要です。やっぱり自分がわかっていないものは作れない、作らせられない、コミットできない。経験が浅いジャンルほど見逃しやすいという、少し皮肉な状況もあります。（良く言えば学習の敷居が下がってる、ともいうけど。）

個人開発者にとってのAI活用は、「超高速で流れるベルトコンベアと一緒に走って、一人で検品と機械のメンテナンスし続ける」ような無理ゲーな体験だと感じています。AIは（課金し続ける限り）疲れません。でも、人間は疲れます。このずっとせかされている感こそが、今の私たちの一番の悩みになっているのではないでしょうか。

一方、チームでの開発では、チームなりの難しさがあります。メンバーが増えれば、こまめな「報告・連絡・相談」も、（わかっちゃいるけど）ストレスです。個々のスキルのギャップや職種のギャップ、業務知識に関するギャップ、チーム間のコミュニケーションや進捗のギャップ、実装すべきタスクとメンバーのスキル、予算、この枠内での品質管理ポリシー、ドキュメント作成、ありとあらゆるところで「調整」が必要です。

さらにはエンドユーザー社内の派閥争いに巻き込まれる、というかユーザー様の社内の部署の壁があって意味不明の「俺聞いてない」問題が勃発したり、こっちの部で受注すると取締役会で蹴られるあっちの部で決済したことにしてもらって…なんて意味不明の根回しが必要だったり。こんなものはもはや「調整不能」です。業務に問題があるなら書類作って指摘できるけど、取締役間の人間関係は指摘してもどうしようもない。どちらにも問題がある場合もあるし、どちらにも「正義」がある場合もある。

開発とは「変えていく仕事」であります。事業であったり、業務であったり、誰かののタスクであったり。それを、変えなければいけない。いつでも変わっていかないといけないけど、それが他人に強制されるのは誰だって抵抗があります。

開発の中でどんな立場にいてもなにか、自分の中で無理にでもモチベーションがあがる何かを探し、マインドを無理にでもキープしていないといけない。なかなかつらい状況がどの現場に行ってもあります。

正直に言うと、私はこの「誰かと調整し続けること」に燃え尽きてしまったと思っています。

チームで働いていたとき、一番消耗したのはコードでも締め切りでもありませんでした。あらゆる情報のギャップから生まれる不信感、徒労感に、じわじわと疲れていったように思います。技術的な問題は原因を特定すれば解決できますが、情報ギャップの問題は解決できるものもあれば、手の届かないものもあります。

そもそも管理職は誰しもそうかと思いますが、「他人をコントロールしようとする行為そのものが、自分を消耗させる」ということです。相手を動かそうとして、思い通りにいかないと苛立って、事情を汲み取ろうとしてさらに疲れて、それでも結果が出なければ自分の責任になる。管理職はそんなもんです。

AIエージェントを使った個人開発では、確かに自分がボトルネックになります。でもそれは、「自分でコントロールできる」ボトルネックです。いつでも休んでいいんです。ペースを落とせます。承認を待たなくていいし、意思決定を誰かに説明しなくていい。失敗しても、その責任は自分だけに帰属します。これが、私が個人開発を選んだ本当の理由です。もう「他人との調整疲れから、さっさと逃げ出したかった」というのが正直なところです。

どちらが「正しい」かではなく、どちらが「自分に合っているか」

ある程度以上の規模のチームでないと作れないものがあるのは、確かにそうです。現時点のLLMモデル・AIエージェントのコンテキスト長では、まだまだ一般の「業務システム」と呼ばれるものを作るのは極めて困難です。ただ、そういう現場で、自分が何に消耗するのかを正確に知っておくことは、とても大切なことだと感じています。

AIエージェントの登場によって、「一人でも、ある程度の規模のものが作れる」ようになりました。人との調整コストを最小化して、自分のリズムで、自分の責任の範囲でものを作れる――そういう選択肢が、現実的になってきた時代だと思います。

AIの稼働時間に自分が付き合いつづけるの、正直、しんどいです。でも、顔の見えない誰かとの情報ギャップに消耗し続けるよりは、ずっと自分らしくいられる。少なくとも、私にとってはそうでした。

ここまでお読みいただき誠にありがとうございました。

このSubstackは読者の皆さんのご支援によって成り立っています。新しいポストを受け取り、私の活動を応援していただくには、無料または有料の購読者になることをご検討ください。

今すぐ登録する

このSubstackは読者の皆さんのご支援によって成り立っています。新しいポストを受け取り、私の活動を応援していただくには、無料または有料の購読者になることをご検討ください。

今すぐ登録する

7世紀の東アジアは、巨大な秩序転換の時代だったのではないでしょうか。

中国では、隋による統一の後、唐 が成立し、東アジア全体へ強い影響力を持つ帝国へ成長していきます。唐は単なる軍事国家ではありませんでした。律令制、巨大な官僚機構、洗練された法体系、国際秩序、そして「文明の中心」としての自己認識を持っていた。周辺諸国にとって、唐とは単なる隣国ではなく、間違いなく「世界の中心」だったのです。

その頃、朝鮮半島では、百済・高句麗・新羅の三国が争っていました。倭国は古くから百済との結びつきが強く、多くの渡来人や技術、仏教文化を百済経由で受け入れていた。しかし7世紀になると、新羅は唐と結びつき、百済を圧迫していく。そして660年、百済は唐・新羅連合軍によって滅ぼされました。

倭国は百済復興を支援するため、大規模な軍を送り込みます。その決戦となったのが、663年の 白村江の戦い でした。

結果は惨敗でした。

『日本書紀』には、多数の船が炎上し、倭軍が壊滅した様子が記されています。この敗北によって、日本列島の支配層は、唐という存在を初めて現実的な脅威として認識したのではないかと思います。

ここで重要なのは、倭国が見たのは単なる「強い軍隊」ではないということです。

彼らが直面したのは、「帝国」というシステムそのものだったのでしょう。

軍事力とは、表面上の兵器の強さや兵士の数だけではなく、それを支える兵站、生産などの国の経済力、そしてその背骨となる統一された行政、司法、徴税、戸籍といった国家の機構、そして「国家とは何か」という概念そのものにおいて、唐は圧倒的に成熟していた。白村江の敗戦は、日本に対して「このままでは国家として飲み込まれる」という危機感を与えたのではないでしょうか。

実際、この戦いの後、日本列島では全体として急激な国家再編が始まります。

九州では水城が築かれ、防衛用の山城が各地に整備される。中央集権化が進み、律令制が整備され、戸籍制度が強化されていく。つまり日本は、「豪族の連合体」から、「国家」へ変わろうとし始めるのです。

そしてその流れの中で成立したのが、古事記 と、日本書紀 でした。

特に日本書紀は、中国の正史を強く意識して編纂されています。漢文で書かれ、編年体を採用し、天皇の系譜を国家史として整理している。つまり日本書紀は、単なる神話集ではなく、「日本という国家は、なぜ正統なのか」を「漢文・漢字」、つまり中国や中華圏の近隣諸国に対して説明・表明するための国家の文書だったのです。

しかしここで、非常に興味深いことがあります。

日本は、中国文明を大量に導入しながら、中国の「天命」思想そのものには入らなかった。

中国では、「天」が皇帝に支配権を与える。王朝が腐敗すれば天命は別の王朝へ移り、新たな皇帝が天下を支配する。つまり、中国皇帝こそが世界秩序の中心であり、正統性の源泉です。

もし日本がこの体系を全面的に受け入れてしまえば、日本の王権は中国皇帝の下位秩序に組み込まれてしまう。

だから日本は、制度は受け入れるが、正統性の源泉だけは共有しなかった。

ここが非常に重要です。

日本書紀では、天皇の正統性は、中国の「天」ではなく、天照大神 や天孫降臨、神武東征、そして列島各地の神々との接続によって説明される。つまり日本は、中国文明を取り込みながら、「中国とは異なる神話体系」を提示したのです。

雄略天皇は葛城山で、自分とまったく同じ姿をした「もう一つの王権」と遭遇する。そして最後には、一言主神へ武器や衣服を献上し、礼を取る。

一言主神が征服されていない。手続きのもと手を取り合った、ということです。

これは単なる怪異譚ではなく、「列島内部に存在する古い権威体系を、ヤマト王権へ統合する物語」として読むことができる。

つまり日本書紀は、中国に対抗できる中央集権国家を構築しながら、同時に列島各地の祭祀権威や土地神を「国家神話」へ接続する作業を行っていたのではないかと、私はそう考えています。

そしてここが、日本国家形成の非常に独特な部分だと思うのです。

キリスト教とイスラム教などは対立しながらも、同じ唯一神の系譜を共有しています。しかし日本は、中国文明を大量に受け入れながら、中国の「天」とは異なる神の体系を提示した。

しかもそれは単なる民間信仰ではなく、「国家の正統性そのもの」として提示された。

私は、一言主神のエピソードには、その国家形成の緊張感が、かなり生々しい形で残っているように感じています。

ここまでお読みいただき誠にありがとうございました。

このSubstackは読者の皆さんのご支援によって成り立っています。新しいポストを受け取り、私の活動を応援していただくには、無料または有料の購読者になることをご検討ください。

今すぐ登録する

このSubstackは読者の皆さんのご支援によって成り立っています。新しいポストを受け取り、私の活動を応援していただくには、無料または有料の購読者になることをご検討ください。

今すぐ登録する

一言主神 は、古事記 と 日本書紀 の両方に登場する神です。最も有名なのは、雄略天皇が葛城山でこの神と遭遇する場面でしょう。

雄略天皇が葛城山で狩りをしていた時、向こうの山中から、自分たちとまったく同じ姿をした一団が現れます。装束も同じ、従者の数も同じ、武装まで似ている。まるで鏡に映したかのように、もう一つの王権が山の中から現れるのです。

天皇は驚き、そして怒ります。「この国に王は自分一人しかいない。お前は誰だ」と問いかける。すると相手は、「我は葛城之一言主大神なり」と名乗ります。

この場面が重要なのは、一言主神が単なる怪異として描かれていないことです。天皇はこの神を討伐しません。追い払うこともしない。むしろ最後には武器や衣服を献上し、礼を取る。『日本書紀』では一緒に狩りまで行います。つまりこの場面は、「人が神に遭遇した話」というより、「二つの権威が向き合った話」として描かれているのです。

私は、このエピソードの鍵が「一言主」という名前そのものにあるのではないかと思っています。

一般的には「もう一人の王」、「異界側の王権」、「国津神側の主権」などと解釈されることが多いかと思います。しかし私は、「一言」とはもっと祭祀的な意味を持っていたのではないかと考えています。

具体的には、山に向かって問いかけ、その返答を読む儀式です。

たとえば、正しい問いかけを行った時には、山から綺麗に一つだけ声が返ってくる。間違った問いかけなら、声が返らない。あるいは複数に乱反射して返ってくる。そうした山の応答・山彦を神意として読む祭祀、慣習が存在したのではないか、と私は推理しています。

もちろん、これを直接示す史料は確認されていません。しかし古代日本の祭祀構造を考えると、そこまで不自然な発想ではないように思えます。

古代の祭祀では、自然現象そのものが神の応答として読まれていました。鹿骨や亀甲を焼き、そのヒビ割れを神意として解釈する卜占はその代表例です。風の向き、水音、鳥の鳴き声、雷鳴などもまた、単なる自然現象ではなく、「返答」として受け取られていた。

つまり重要なのは、人格神が人間の言葉で喋ることではなく、自然そのものが応答することなのです。

この視点で雄略天皇の場面を見ると、構造がかなり変わって見えてきます。

雄略天皇は、「この国に王は一人だ」と宣言する。しかし山は、その言葉に対して、まったく同じ姿をした「もう一人の王」を返してくる。私はこれを、「山そのものによる応答」として読むことができるのではないかと思っています。

つまりあの場面は、「お前は本当に王なのか」という山からの問い返しなのです。

そして雄略天皇は、その返答を受け入れる。ここが重要です。彼は一言主神を征服しない。むしろ武器や衣服を献上し、礼を取る。それは敗北というより、権威の承認に近い振る舞いです。

さらに私は、この物語の背景には、葛城氏 の存在があるのではないかと考えています。

葛城山周辺は、古代日本でも極めて重要な地域でした。奈良盆地と河内平野を結ぶ境界に位置し、山岳祭祀、交通路、軍事、豪族勢力が集中する場所だった。葛城氏は、その地域に根を張った有力豪族です。

そう考えると、一言主神とは単なる人格神ではなく、「葛城の祭祀権威そのもの」だったと考えるのが自然なのではないでしょうか。

すると雄略天皇のエピソードは、「葛城の権威に対して正式に仁義を通し、承認を受けた物語」として読めるようになります。だから相手は“同じ姿”で現れるのです。単なる神ではなく、対等に近い権威だからです。

古代日本では、山と神と豪族と政治はまだ分離していませんでした。山の神とは、その土地の権威そのものでもあった。だから一言主神との遭遇は、単なる神話ではなく、祭祀であり、外交であり、王権認証でもあったのではないか。

私は、一言主神という存在には、まだ国家に完全統合される前の、日本列島の古い権威構造の空気が色濃く残っているように感じています。そして、それらと「武力ではなく仁義礼智でつながっていった」ということを示すエピソードとして記載されているのではないかと思っています。

（お隣のどこか国の皇帝とは違うんですよ、ということが言いたいんじゃないかな、と。）

ここまでお読みいただき誠にありがとうございました。

このSubstackは読者の皆さんのご支援によって成り立っています。新しいポストを受け取り、私の活動を応援していただくには、無料または有料の購読者になることをご検討ください。

今すぐ登録する

『オラクル綾乃』は、九星気学、経済情報、地経学、孫子の兵法、そしてLLMによる分析ワークフローを組み合わせるために作った、AI生成キャラクターであります。

とはいえ、最初から今の「AIマクロ戦略家」という方向性で生まれたわけではなく、最初にあったのは、もっと素朴な発想でして。

九星気学を使って、人と人の相性やいわゆる『世相』、日本の経済や社会の流れを大まかに読めるのは感覚的にわかっていました。たいていの日本人なら「干支」は心の芯まで入っていると思います。当然のことながら、「今年は午年」だからって行動することはないけど、なんとなく「午年」っぽく収束（午は発散？）していくことだろし、なんとなく季節や方位、「午」の象意とかから入っていくと「正午は九紫火星なんですよ」なんていうと「それっぽく聞こえる」というか。日…

Read more

現代の情報空間で起きている問題の一つは、単にニュースや事件、情報の量が多すぎるということだけではありません。より本質的な問題は、ひとつのニュースを理解するために必要な前提知識そのものが極めて膨大になっている、ということです。

政治や経済の出来事を読むには、その背後にある地理、歴史、制度、産業構造、国家間関係、社会心理まで含めて把握しなければなりません。表面に現れたニュースは、単独の出来事ではなく、長く積み重なった構造の一部として現れています。

しかし、日々流れてくる情報は、その構造を丁寧に理解する余裕を与えてくれません。出来事は短い見出しに切り詰められ、過去の経緯や背景は省略され、読者は断片だけを受け取ることになります。

しかも、その断片は次々に更新されるため、ひとつの問題を深く理解する前に、別の問題へ注意…

Read more

このSubstackは読者の皆さんのご支援によって成り立っています。新しいポストを受け取り、私の活動を応援していただくには、無料または有料の購読者になることをご検討ください。

今すぐ登録する

Read more

1. メインテーマである九星の象意について

   状況に応じてプロンプトに入れるのはどうしたらいいんだろう。

   結局、RAGっぽくしなきゃいけないのか？戸惑う。

   現状はファイルベースでやっている象意辞書としてmd形式で星ごとの象意列挙。

   メッセージ生成モデルはOpenAIのAPIでモデルは適切に切り替えているが、最近のモデルはコンテキスト長がデカいのでファイルを丸ごと入れても大丈夫のようだ。

2. WebSearchツール

   LLMでWebSearchツールをオンにしたりオフにしたり使い分けている。無制限に使用すると料金と実行時間でコストがかかるだけ。多段のワークフローで調整中。

3. アイキャッチ画像生成

   事前生成のテンプレートとテーマに沿ったメインビジュアルの生成画像を重ね合わせている。画像生成モデ…

Read more