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マクロ戦略家」という方向性で生まれたわけではなく、最初にあったのは、もっと素朴な発想でして。

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

ただ世の中のニュースや市場の動きは海外、特にアメリカに対して動くことが多く、その中ですっごく「西洋」の動きが日常の中に入ってきているけど「東洋」の技術・占星術である九星がどんな感じであてはめられるんだろう？もしLLMで（無理やり）九星をあてはめたらどんな感じになるんだろう？というのが疑問の始まりで、いわゆる海外発の普通の経済ニュースをちょっと違う角度から分析できないだろうか。そういう小さな仮説から始まりました。

リポジトリを作りはじめて、今日までおよそ340日余り。その間にやってきたことは、最初から仰々しい『AIメディアの構築！』というより、日々の細かい問題解決の積み重ねでした。記事を作り、画像を作る。プロンプトを直す。GitHub Actionsを直す。Ghostへの投稿で失敗する。Xの投稿仕様に合わせる。JSONが壊れる。LLMの文章が抽象的すぎて使えない。出力はきれいだが、読んでみると何も言っていない。そのたびに、仕組みを少しずつ変えていきました。

最初の頃に時間がかかっていたのは、主に画像生成モデルでのキャラクターとブランドの形成でした。文章を生成するプロンプトはだいたい「きまる」のですが、画像生成プロンプトでの、ポーズや髪型、服、髪飾り、背景、色、地球儀、背景の金融チャートなどのこれらのプロンプトが全く定まらない。何より、去年のDALL-EとかStableDiffusionとかモデルが変わるとプロンプトが全く変わっていく。また画像生成するにもそこそこ時間がかかります。一昨年までは生成された指の数が問題になっていましたが、去年の今頃はもうほとんどそんなことはなくなって、遠慮なく指先も加えることができるようになりポーズもいろいろ試しました。地球儀や水晶玉を持っているポーズはやっぱり『占い師っぽさ』にはかかせませんから。プロンプトと成果物を調整しながら、大量に画像を生成し、顔や衣装の再現性や一貫性のなさに打ちのめされながら、「再現性のあるオラクル綾乃」のイメージを作っていきました。

同時に、Ghostというメディアに記事を自動追加し、Xから導線を作り、週刊のまとめをMediumに作ってみたり、GitHub Actionsで自動化するようになりました。最初の構成は、かなり素朴でした。LLMに記事を書かせる。タイトルを作らせる。必要なら翻訳する。必要なら画像を作る。必要ならX用に短くする。単発の処理をつないで、なんとかコンテンツを出していました。

この段階で、LLMの最初の壁が見えてきました。

LLMは、それらしい文章を書くのが得意です。九星気学と経済ニュースを混ぜれば、雰囲気のある文章はすぐに出ます。九星の象意や木火土金水の陰陽五行。そうした象意を使えば、どんなニュースにもある程度の説明を与えることができます。

けれど、扱う対象が広がるほど、文章は抽象的になっていきました。国家、産業、物流、金融、制裁、政策、制度、法的争点、テック産業、社会不安。これらも九星の象意に当てはめれば文章は生成できます。むしろ、できてしまいます。しかし、象意を当てはめる範囲が広いほど、どの制度の話なのか、どの産業構造の話なのか、どの政策手段の話なのか、どの市場メカニズムの話なのかがぼやけていきます。文章としては美しいが、分析としては解像度が低い。そういう問題が出てきました。

そこで、最近になって専門家フェーズを入れました。

専門家フェーズの役割は、九星で読むべき焦点を絞るための前処理です。まず、ニュースの現実側の争点を切り分ける。これは地経学で読むべき話なのか、国内政策や法制度で読むべき話なのか、金融市場で読むべき話なのか、テック産業で読むべき話なのか、市民社会の安定性として読むべき話なのか。テキストの中から「専門用語」や「登場人物」、「対象物」、「場所」など話題となる「キーワード」を抜き出し、その焦点に向かって適切に、九星の象意を重ねるようにしました。

このようにすると、何となくの象意の流れの説明だけでなく、それぞれの専門家によって事件やニュースのストーリーを、見るべきキーワードで「構造化」することができました。経済でも司法でも政治でも地政学でも、セオリーとなる「イベント」や「流れ」、「手続き」、「リスク」などのフレームがある、ということに気づいたわけです。専門家フェーズで「これは供給網のチョークポイントの話だ」「これは法制度上の執行リスクの話だ」「これは金融市場のポジショニングの話だ」と先に絞ると、九星の象意を当てる場所が明確になります。

地経学を取り入れたのも、この流れの中です。地経学は、やはり昨今のニュースにおける地政学と経済問題を同時に扱うことが多くなり、例えば戦争と経済を別々の専門家に任せるのが厳しくなってきました。また地域や方角、チョークポイント、どこに依存関係があり、誰がゲートキーパーになるのか。そうした現実側の構造を先に把握することで、九星の読みにより具体的な「場所」も象意に置けるようになりました。

孫子の兵法も、本当に最近、入れた観点です。

専門家フェーズでニュースの論点を絞り、九星でその象意と推移を読む。そこまではできるようになりました。しかし、記事として説得力というか面白さを盛り込むには、もう一段必要でした。九星気学的なシステムだけでも流れからどうなっていくのかの解説文は生成できます。しかしそれもやんわりというか、決定論的な「次はこうなるから気を付けましょう」では面白くない。もう一歩、こういうシチュエーションでは何を材料に何を判断するべきなのか、その一押しを『東洋の技術・知恵』で何とかしたい、と。

孫子の兵法は、その「判断基準と取るべき行動」を当てはめるために加わえました。（ぶっちゃけ男の子なら三国志で奇門遁甲知らない奴いないでしょ？）構造分析と九星読解のあとに、戦略的な焦点を与えるためです。現在のオラクル綾乃は、そのような層の重なりとして動いています。

この様に要求（欲求？）が高まったのも、大きな転換点としてLLMを「ひとつの書き手」として使うのをやめたことです。

初期の実装では、ひとつの大きなプロンプトに多くの役割を詰め込んでいました。ニュースを調べる。構造を分析する。九星で読む。オラクル綾乃の文体で書く。SNS用に変換する。これを一回のLLM呼び出しでやろうとすると、必ずどこかが薄くなります。調査を重視すると文章が弱くなる。文章を重視すると事実が弱くなる。九星を強めると詩的になる。経済分析を強めると、オラクル綾乃である意味が薄くなる。さらにWeb_Searchツールはすでにつかえましたが、「いつ検索するのか」のタイミングが固定、つまり与えたプロンプトから検索キーワードを決めてまず検索し、検索結果を使って、文章を生成する、という挙動でした。その後、モデルが賢くなって「自分で判断」するようになると、前のモデルで使っていたプロンプトはご破算になってしまいました。

そこで、LLMを組織として使う方向に変えました。（当然、コストも増えました。）

まず、リサーチャーを置く。リサーチャーは、観測可能な事実、主体、統計、タイムライン、一次情報、未解決点を集める。必要なだけ、確認可能な材料を集める役割です。

次に、専門家を置く。専門家は、ニュースごとに適切な視点・観点を選び、争点を切り分け、分解するためのフレームワークを提供するのです。地経学、国内政策・法制度、金融市場、テック産業、市民社会の安定性など。どの専門家が読むべきかを判断させ、その専門家での論点の抽出や「専門家の見方」で構造化することで、すべての出来事がそれぞれに適した「型」で取り出せるようになりました。

その次に、九星の読解者を置きましたが、ここでもLLMにすべてを任せるのは危険でした。LLMは、そもそも多少の「五行や九星の知識」を持っています。これがやっかいでした。それらしく説明できますが、私からするとでたらめな解釈をでっちあげていることが多々あります。ハルシネーションというやつです。

そこで、ある程度の九星の前処理を決定論的に分離しました。Pythonのロジックとして暦から中宮の星を求め、九星から各星の配置を逆算し、象意候補を辞書から抽出したり。（マスター化も考えましたがSkyfield APIで太陽と地球の位置情報から立春が算出できたり。）そんな感じでなんとなくプロンプトに暦カレンダーを突っ込むのではなく、データとロジックで処理した結果をJSONやYAMLなどのフォーマットにしてプロンプトに入れ、どの対象にどの象意を当てるかを明確に指示する。これによって、九星の読みは雰囲気ではなく、辞書と配置に基づく分析に近づきました。

さらに、九星の流れに対する孫子の戦略解説を生成した後で、執筆者としての『オラクル綾乃』が記事を書き、編集者が検証・校閲、つまり事実確認や読者目線での表現の緩和、抽象表現の削減、監査ログの保存を担当します。最後にSNS担当者が、Ghost記事をXやBluesky向けの投稿に変換します。

これは、単なるマルチエージェントというより、LLMの「組織化・階層化」です。

単に役割を分けるて分業することだけではなく、あるLLMの出力を次のLLMの入力にすることです。リサーチャーの成果物を専門家が読み、専門家の分析を九星読解者が読み、九星読解と専門分析を戦略レンズが読み、統合執筆者が記事にし、編集者が検証し、SNS担当者が配信用に変換する。各フェーズで成果物を保存し、後から検証できます。（させます。）

このような『構造』にしたことで、失敗が明確にキャッチできるようになりました。

単発生成では、記事が悪くても原因がわかりません。どこかのプロンプトがうまくいかなくても全部が混ざってます。そもそもLLMは毎回、文言が変わるので一発勝負なところも多分にあります。統計的に処理できるのであれば20回生成させて平均取る、とかもあろうことかと思いますが、文章はそんなことはできません。また長大なプロンプトは毎回、料金が高いので試行錯誤にも限界があります。（APIの料金だけで1日で50＄とか行くときはいきます。）

そして、LLMの性能向上も、この設計に大きく影響しました。初期のモデルでは、長い文脈を安定して扱えず、JSONも壊れやすく、複数の役割を同時に持たせると指示が混ざりました。そこで、かなり強くプロンプトで縛る必要がありました。

その後、structured outputsやPydanticスキーマを使えるようになり、JSONの破綻はかなり減りました。長コンテキストのモデルを統合フェーズに使うと、単なる抽象論のふわっとした文章ではなく、具体的な文言や論点のはっきりした長いけど意味が通る文章が出せるようになりました。

LLMの性能向上だけではありません。コストダウンも非常に大きいです。長コンテキストの高性能モデルが遠慮なくバンバン叩けるようになると。そこは非常に大きかったです。もちろんこれらを製造するのにCodexとClaude Codeもガンガン使っています。（こいつらのサブスクもばかにならないお値段です。）

そんなわけですが、この340日でやってきたのは、記事を作ることだけではありませんでした。記事を作るための情報・材料・思考の流れを、どこまでシステムに落とせるかを試してきた時間でした。

オラクル綾乃は、表に出るときはひとりのAIキャラクターです。九星気学、孫子で世相の流れを語るAIマクロ戦略家です。

けれど裏側では、ひとりではありません。リサーチャーがいて、経済や法律、地経学などの専門家がいて、九星読解者がいて、孫子の戦略レンズがあり、統合執筆者がいて、編集者がいて、SNS担当者がいます。さらに、記事の投稿、SNS投稿、アイキャッチ画像生成、専門用語の辞書作成など各種のGitHub Actionsのワークフローが、それらを支えています。

オラクル綾乃というキャラクターは、ひとつの顔でありながら、実際にはひとつのシステムです。

340日かけて生まれたのは、完成されたシステムなどではなく、記事の作成で必要な、情報をどう圧縮し、どの争点に焦点を当て、どの象意で読み、どの不確実性を明らかにし、どの論点やストーリーを読者に渡すか。オラクル綾乃プロジェクトは、そのための試みです。

答えではありません。むしろ、問いを処理するための構造です。その構造を、AI生成キャラクターの姿にまとめたものです。

AIマクロ戦略家オラクル綾乃が生まれるまでの340日は、AIに記事を書かせるための時間ではありませんでした。

LLMを、ひとりの文章生成器から、ひとつの分析組織へ変えていくための時間でした。

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

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

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

しかも、その断片は次々に更新されるため、ひとつの問題を深く理解する前に、別の問題へ注意が移ってしまいます。情報は増えているのに、理解は深まらない。これが、現在の情報環境における大きな矛盾であり、とても大きな問題です。

オラクル綾乃プロジェクトを通して九星気学で見せようとしているのは、この断片化されて膨大な量の情報で構成されるマクロの構造です。未来を断言することではなく、まず現象を分解・解体し、何がどこで詰まり、どの方向へ流れようとしているのかを読み解くこと。九星気学を、単なる運勢占いや性格診断としてではなく、複雑な情報を整理するための象意体系として扱うこと。そこに、オラクル綾乃プロジェクトの中心があります。

九星気学は、物事を単に分類するし相性を見るだけのものではありません。むしろ、流れや遷移を捉えるためのシステム・OS・ツールとして使うことができます。ある力が拡大し、別の力が停滞し、圧力が蓄積し、やがて別の形で表面化する。社会や市場や政治の出来事は、常にこうした動きの中で発生しています。九星の象意は、その複雑な動きを一度分解し、性質ごとに整理するための補助線になります。

もちろん、九星気学は科学的な因果モデルではありません。経済学、政治学、歴史学、統計モデルの代替になるものでもありません。しかし、あまりにも複雑な現象をすべて細部まで保持し続けることが難しいとき、象意によって構造を圧縮し、出来事の性質や流れを整理することには意味があります。重要なのは、現実を九星に雑に置き換えることではなく、現実を読み解くための座標系として九星を使うことです。

オラクル綾乃プロジェクトでは、この九星による構造分解をLLMと組み合わせています。LLMは大量のテキストを扱えますが、単にニュースを要約するだけでは、背後にある構造までは十分に見えてきません。そこで、出来事を一度、九星の象意へマッピングし、そのうえで関係性や流れを読み直します。LLMを文章生成の道具としてだけではなく、前提知識と現象を接続し、複雑な文脈を整理するためのエンジンとして使うのです。

ここで重要なのは、占いらしい占断を言い切ることではありません。むしろ、占断を減らし、構造を明確にすることです。偶然に見える出来事を、より大きな流れの中に置き直す。個別のニュースを、配置や関係性の中で読み解く。オラクル綾乃が目指しているのは、神秘的な予言ではなく、九星という古い象意体系、記号体系という言語・シンボルを使った情報空間の整理です。

その意味で、オラクル綾乃は「当てる占い」よりも「構造を見る占い」に近い存在です。短期的な予測だけを目的にするのではなく、いま何が拡大し、どこに停滞があり、どの流れが詰まり、どの力が表面化しつつあるのかを捉える。予測よりも先に、構造を理解する。そこに、このプロジェクトの価値があります。

オラクル綾乃が目指しているのは、情報の断片に反応することではありません。過剰なニュースと膨大な前提知識を、九星という座標系で一度分解し、再配置し、流れとして読み直すことです。現象をそのまま受け取るのではなく、構造へ戻す。構造を見たうえで、次にどの方向へ圧力が動くのかを考える。そのための視点を提供することが、このプロジェクトの役割です。

九星で構造を解体し、流れを掴む。

それは、未来を断言するための言葉ではありません。複雑すぎる現代の情報空間を、人間がもう一度考えられる形に戻すための方法です。ニュースの背後にある地理、歴史、制度、経済、社会心理まで含めて、情報をただ消費するのではなく、構造として読み直す。オラクル綾乃は、そのためのキャラクターであり、そのための視点であり、そのためのメディアです。

余談ですが、私は京極夏彦先生の「京極堂シリーズ」が大好きです。物語の終盤（と言っても謎解きが長いので真ん中あたりから終盤が始まっちゃうんだけど）、京極堂が事件の謎ときを「憑き物落とし」としてやるんですが、それが複雑に絡み合った謎や矛盾を一つずつ解きほぐしていくという事件の（そして毎回、複数の事件が同時進行しているストーリー）の「解体」作業です。そして、それによって犯人や共犯者たちの抱えていた矛盾や葛藤が解き放たれていく、お祓いのような謎解きが大好きです。

九星という物差しで、複雑な事件や困難な将来を、解きほぐしていきたい。そんな気持ちでやっています。

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

今すぐ登録する

オラクル綾乃プロジェクトでは、現在、LLMを用いて九星気学の解釈を行う記事生成エンジンを開発しています。当初は単に、九星の象意を物事に当てはめ＝言い換えて、九星の相性や今の位置や次の位置（坎宮→離宮など）の遷移・循環で説明し、元の物事の説明に戻すと占いっぽいテキストになる、というかうまいこと説明できている、という感じでした。

ただし、それだけでは「っぽい」だけで実際にはいろいろな前提知識や歴史的経緯が必要であり、ちゃんとした「事件」を「九星で解説する」記事を作成するにはそれなりのパイプラインを構築する必要がありました。またプロンプトもそれなりに調整する必要もあるし、割と大変な作業ではあります。（それはそれでおいおい解説するかもしれないししないかもしれないし今ここでのテーマとはそれるのですっ飛ばしますが）

ただ昨今のOpenAIやClaude Sonnetなどの「物事を説明する能力」「物事を解釈する能力」「物事を他に例える能力」「物事を別のシンボルへ置き換える能力」が飛躍的に上がっている気がします。もともとLLMは翻訳用途に研究がスタートしたプロジェクトであり、そもそもがうまいこと言い換える機会学習モデルであり本職こそ翻訳エンジンであるわけです。

そこで、英語（で説明される事象）→日本語（で説明される事象）の代わりに、何らかの言語（で説明される事象）→九星の象意（で説明される事象）とやってみたら意外とうまくいっている、という感じです。

私はたまたま九星気学メインでやっていますが、他の占星術や記号論的解釈で事象を説明させるのはかなりスジの良いLLMの使い方なんじゃないかと思っています。

また単なる記号論と「占星術」の違いは占星術はシステムとして「循環」や「遷移」などの「状態」と「動き」が説明できることです。これによって単なる記号の置き換えに終わらず、置き換えた後どうなるのか？が占星術のシステムによって導出できるのです。

また現実の事象はアクターや状態が多く、それぞれ別の事象である動きとその結果は頑張って追ってもそれはあくまで個別の事象であり（観測結果を統計で頑張っても）、あんまりまとまりのない結果になりそうですが、ここで上記の翻訳エンジンを投入し、いったん「象意・星」や「五行」などにマッピングしてしまうと、一まとめで「なんとなくその先が説明できる」のです。占星術が技術であり、システムであるというのはそういうことです。

システマティックに、ある程度の挙動は説明可能になってしまいます。もちろん、この「説明ができる」という言い方にはいろいろ問題があるけど、とりあえず「お作法に従って説明ができる」のは本当に実際にそうです。水生木、木克土などで無理やりにでも解釈できる、ということで、あなたは水星の人だから木星の彼のいいところを自然に伸ばすことができるのよ、なんてそれっぽい（しかも何となく当てはまっている）言い方ができてしまうわけです。

つまりざっくりとした「マクロの動き」が説明可能なんです。このように個別の人物や事件、契約の流れをまとめて「象意とそれをつかさどる星」にマッピングしてマクロの動きを説明すると、個別のバラバラに動いているアクターの状態や遷移を「圧縮」して補足可能になっているんじゃないかなと。

つまり、象意に当てはめることで情報の圧縮を行い、次の結果や象意の解釈によって情報の解凍を行っているんじゃないか、そんな風に感じている昨今です。

今後も九星気学メインですが記号論とLLMについて研究していこうかなと思ってます。

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

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

今すぐ登録する

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

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

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

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

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

2. WebSearchツール

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

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

   事前生成のテンプレートとテーマに沿ったメインビジュアルの生成画像を重ね合わせている。画像生成モデルもOpenAI。ただしモデルによってプロンプトと成果物がだいぶ変わるので、正直、悩ましい。