AI 時代に「世界を閉じる技術」が価値を持つ（前編）

AI の本質は変わっていない

ChatGPT の登場以来、世界中で「AI がついに人間に追いついた」という声が聞こえる。確かに自然な会話ができ、複雑な質問にも答え、創造的な文章まで書いてくれる。まるで人間のような知性を持ったかのように見える。

しかし、エンジニアとして断言したい。AI の本質は何も変わっていない。変わったのはインターフェースだけだ。人間との対話能力が飛躍的に向上した。音声認識の精度が上がり、自然言語処理が洗練された。しかし、その裏側で動いている仕組みは同じである。

AI は依然として「計算可能な世界」でしか動けない。

これはどういうことか。AI がどれだけ賢く見えても、扱えるのは数値化され、構造化され、ルール化された情報だけなのだ。曖昧で、文脈依存で、無限の解釈可能性を持つ現実世界を、そのまま扱うことはできない。

だからこそ、AI が人間に歩み寄っているように、人間も AI に歩み寄る必要がある。

多くの人は「AI が進化したから、人間は何も変わらなくていい」と考える。しかし、それは大きな誤解だ。真の協働を実現するには、双方向の歩み寄りが不可欠なのだ。そして、その「歩み寄り方」を、実はエンジニアたちは何十年も前から実践していた。ただ、それが普遍的な価値を持つことに、誰も気づいていなかっただけである。

「世界を閉じる」技術

無限を有限に変換する創造的行為

エンジニアが毎日やっている仕事を、一言で表現するとどうなるか。プログラムを書く？システムを設計する？バグを修正する？

いや、もっと本質的には、彼らは「世界を閉じる」作業をしている。

これは比喩ではない。文字通りの意味だ。無限の可能性を持つ現実世界から、必要な要素だけを抽出し、有限の、扱いやすい形に変換する。これが「世界を閉じる」ということだ。世界を閉じるとは専門用語ではなく、私の造語になるが、専門的には形式化することを指す。

例えば、「顧客」という概念を考えてみよう。現実の顧客は、趣味も、家族構成も、今朝の朝食も、無限の属性を持つ複雑な存在だ。しかし、ビジネスで扱うためには、この無限の情報から必要なものだけを選び出す必要がある。

• 名前
• メールアドレス
• 購買履歴
• 最終アクセス日時

このように、無限の属性から有限の属性を選び出す。これが「世界を閉じる」第一歩だ。

AI 時代の革命的な「閉じ方」

しかし、ここで重要なのは、AI 時代の「世界を閉じる」技術は、20 年前とは全く違うということだ。

かつて「イノベーティブな組織」を評価しようとすれば、どうしていただろうか。

• 新規事業の数
• 特許出願数
• 研究開発費の比率

こんな単純な数値に頼るしかなかった。誰もがこれでは本質を捉えられないとわかっていたが、他に方法がなかったのだ。

しかし、大規模言語モデル（LLM）の登場により、状況は一変した。今では、次のような複雑な要素も扱えるようになった。

• 会議での発言パターンから読み取る創造性指標
• Slack でのアイデア共有ネットワークの構造分析
• 失敗事例の共有頻度と、そこからの学習速度
• 部門を超えたコラボレーションの質と量

つまり、複雑な現象を、その複雑さを保ったまま計算可能にできるようになったのだ。

世界モデルという新しい概念

AI 研究の最前線では、これを「世界モデル」と呼ぶ。現実世界の一部を切り取り、計算可能な形で表現したものだ。そして今、LLM は既に膨大な「世界モデル」を内部に持っている。言語の使い方、概念間の関係、さまざまな知識。これらはすべて、人類が長年かけて「閉じてきた」世界の集大成だ。

しかし、ここに決定的な限界がある。LLM は既存の世界モデルを活用できるが、新しい世界を「閉じる」ことはできない。あなたの会社独自の評価基準、あなたのチーム特有のコミュニケーションパターン、あなたの業界の暗黙のルール。これらを「閉じる」のは、人間にしかできない創造的行為なのだ。

世界を閉じる本当の意味：最適化への道

LLM は既存の世界モデルを活用できるが、新しい世界を「閉じる」ことはできない。これは人間にしかできない創造的行為だ。

しかし、そもそもなぜ「世界を閉じる」必要があるのか。

答えは明確だ。世界を閉じることで、初めて最適化が可能になるからだ。

無限の可能性を持つ現実世界は、そのままでは最適化できない。何を最大化したいのか、何を最小化したいのか、制約条件は何か。これらを明確に定義し、計算可能な形に変換して初めて、最適解を求めることができる。

エンジニアが毎日やっているのは、まさにこの作業だ。無限の可能性から必要な要素を抽出し、自動的に検証可能な形に落とし込む。そうすることで、短期的にも長期的にも最適なシステムを構築できる。

なぜ人間には最適化が難しいのか

認知の限界という構造的問題

ここで、根本的な問題に向き合わなければならない。なぜ優秀な経営者やマネージャーでも、組織運営で失敗を繰り返すのか。答えは、人間の認知能力の限界にある。

心理学者ジョージ・ミラーが発見した「マジカルナンバー7±2」。人間が同時に意識できる要素の数は、せいぜい 5〜9 個程度だという。これは 1956 年の研究だが、今でも覆されていない人間の根本的な制約だ。この制約が、組織運営において何を引き起こすか。部分最適の罠である。

採用担当は「優秀な人材をできるだけ多く」と考える。育成担当は「最高の研修プログラムを」と張り切る。評価担当は「公平で詳細な制度を」と作り込む。

それぞれは正しい。しかし、全員が自分の見える範囲で最適化した結果、組織全体が機能不全に陥る。

部分最適の総和は必ずしも全体最適と一致するとは限らず、むしろ全体としては悪い選択の場合もある。組織も同じだ。各部門が最高のパフォーマンスを出しても、組織全体が最高のパフォーマンスを出すとは限らない。むしろ、部門間の衝突により、全体のパフォーマンスは著しく低下することもある。

最適化を可能にする 2 つの要素

では、どうすれば全体最適化が可能になるのか。ここでエンジニアリングの知恵が光る。

最適化には 2 つの段階がある。「世界を閉じる（形式化）」と「自動検証の仕組み作り」だ。

第 1 段階：世界を閉じる（形式化）

例えば「優秀な人材」を評価する場合を考えてみよう。何をもって「優秀」とするのか？売上貢献度？イノベーション創出力？チームへの好影響？

これらを明確に定義し、測定可能な形に落とし込む。目的関数は何か、評価指標は何か、重み付けはどうするか。これが「世界を閉じる」ということだ。そして、これは人間にしかできない創造的行為だ。

第 2 段階：自動検証による長期的最適化

しかし、評価基準を作っただけでは、短期的な最適化しか実現できない。時間軸で考えた長期的な最適化には、自動検証の仕組みが不可欠だ。

例えば、新しい評価項目を追加した時、それが既存の評価体系と矛盾していないか？昇進基準と報酬基準に齟齬が生じていないか？これらを自動的に検証できなければ、短期的には良く見えても、長期的には組織に歪みを生む。

エンジニアリングでは、これを「テスト」という自動検証の仕組みで実現している。組織運営でも同じ発想が必要だ。

検証可能性を失った時に起きること

技術的負債という教訓

ここで、検証可能性を軽視するとどうなるかを示す、エンジニアリングの世界の教訓を共有したい。

それが「技術的負債」という概念だ。

技術的負債とは、簡単に言えば「今は動くが、将来必ず問題になるコードやアーキテクチャ」のことを指す。納期に追われて適当に書いたプログラム、場当たり的な修正、ドキュメントのない複雑な処理。これらはすべて「負債」として蓄積される。

そして恐ろしいのは、この負債には利息がつくということだ。放置すればするほど、修正は困難になり、コストは指数関数的に増大する。ちょっとした修正に数時間かかっていたのが、数日、数週間、最終的には数ヶ月かかるようになる。これが技術的負債の恐怖であり正体である。

組織的負債という見えない脅威

私は経営をしていて確信した。組織にも、まったく同じ構造の「組織的負債」が存在する。

これを最も分かりやすく示すのが、ボーナス制度の例であり、ボーナス制度の罠：組織に残す見えない負債の構造的問題という記事でも以前に詳しく解説している。

友人の経営者から「業績が好調だからボーナスを出すことにした」という話を聞いた時、私は強い違和感を覚えた。一見すると従業員思いの素晴らしい判断に見える。しかし、これは典型的な組織的負債の始まりなのだ。

人間の認知バイアスが生む罠

なぜボーナスが負債になるのか。それは人間の認知システムに原因がある。

行動経済学の研究によれば、人間には「参照点依存性」という特性がある。一度設定された基準（この場合はボーナス）が、その人にとっての「普通の状態」として記憶される。さらに「損失回避性」により、同じ金額でも「もらえる喜び」より「もらえなくなる苦痛」の方が約 2 倍強く感じられる。

つまり、ボーナスを出すことで、将来にわたって「期待値を満たし続ける」という債務を負うことになる。これが組織的負債だ。

私自身の痛い経験

実は、私自身がこの罠に見事にはまった経験がある。

キカガクを創業した当初、会社が順調に成長していた時期のことだ。従業員のモチベーションを上げようと、深く考えずに様々な施策を導入した。期待を込めた昇進、感覚的な昇給、新しい福利厚生。

その時、親友に言われた言葉が今でも忘れられない。「うまくいっている時は良いよね」。当時の私には、この言葉の真意がまったく理解できなかった。業績も順調で、従業員も喜んでいる。何が問題なのか、と。

コロナ禍で売上が激減した時、親友の言葉の意味が痛いほどわかった。

期待値込みで昇進させていた人材の再配置、感覚的に決めていた給与体系の見直し。すべてが「過去の自分」との戦いになった。相手からすれば「昇進時には評価されたのに、なぜ今は違うのか」という当然の疑問が生じる。

検証可能な基準なしに行った判断は、すべて組織的負債となって返ってきた。

つまり、検証可能性の欠如は、長期的な最適化の失敗を意味する。短期的には良く見えても、時間の経過とともに最適性は失われ、修正コストは指数関数的に増大する。

エンジニアが実践する長期的最適化

検証の仕組みがない開発の現実

ここで、ソフトウェア開発の現場で起きている「不都合な真実」を共有したい。

一般的に、プログラマーの仕事といえば「新しい機能を作ること」だと思われている。しかし、検証の仕組みがない開発現場では、驚くべき現実がある。

作業時間の 8 割が「デバッグ」と呼ばれる不具合修正に費やされている。

これはどういうことか。新しい機能を追加した後、それが既存のシステムにどんな影響を与えたかを、1 つ 1 つ手作業で確認しなければならない。これを「ブラックボックステスト」と呼ぶ。中身が見えない箱を外から叩いて、動作を確認するようなものだ。

なぜエンジニアは「テスト」を書くのか

この状況を打破するために、現代のエンジニアリングでは「テスト」という仕組みが広く採用されている。

多くの人はこう考えるかもしれない。「テストを書く時間があれば、もっと新しい機能を作れるのでは？」

しかし、これは短期的な視点でしかない。エンジニアがテストを書く本当の理由は、長期的な開発速度を最適化するためだ。

テストがあるシステムでは、新しい機能を追加した瞬間に、その影響が明確になる。「この変更によって、他のどこが壊れたか」が即座に判明するからだ。

つまり、テストとは「検証可能性」をシステムに組み込むことで、長期的な最適化を実現する仕組みなのだ。

テスト駆動開発がもたらす革命

さらに進んだアプローチとして、「テスト駆動開発（TDD）」という手法がある。

これは、機能を作る前にまずテストを書くというアプローチだ。一見すると順序が逆に見えるかもしれないが、これにより驚くべき変化が起きる。

デバッグに 8 割の時間を費やしていた開発が、その大部分を削減できるようになる。

なぜなら、最初から「何が正しい動作か」を明確に定義し、それを満たすように作るからだ。これはまさに、「世界を閉じて検証可能にする」というプロセスそのものだ。

「テスト」という言葉の本当の意味

ここで重要な誤解を解いておきたい。

ビジネスの世界では「テスト」というと、「試しにやってみる」「小規模で実験する」という意味で使われる。

しかし、エンジニアリングにおける「テスト」は全く違う意味を持つ。

エンジニアリングのテストとは、「期待される動作を厳密に定義し、それが常に満たされているかを自動的に確認する仕組み」のことだ。

重要なのは「自動的に確認する」という点だ。期待される動作の定義（チェックリスト作成）は人間が行うが、その確認作業はコンピュータが自動で実行する。人間が毎回チェックリストを見ながら確認するのではない。これにより、確認漏れや人的ミスを防ぎ、継続的に品質を保証できる。

つまり、「世界を閉じる」（期待動作を定義する）のは人間の創造的行為だが、その検証は自動化される。この組み合わせが、長期的な最適化を可能にする。

リファクタリング文化という知恵

さらに知って欲しいこととして、多くのエンジニアチームではリファクタリングの文化がある。リファクタリングとは、既存のコードを改善する作業だ。新しい機能を追加するのではなく、既存のコードをより良い形に整える。

例えば、週の作業時間の 20% を既存コードの改善に充てるというルールだ。月曜から木曜は新機能の開発。そして金曜日は「リファクタリング」の日のように。

一見すると生産性が下がるように見える。しかし、この習慣により、エンジニアたちは次のような恩恵を受ける。

• コードの品質が保たれる
• 将来の開発が速くなる
• バグが減る
• チームの知識が共有される

エンジニアたちは、技術的負債の恐ろしさを知っているからこそ、定期的な「清掃」を怠らない。

これこそが、エンジニアリングから組織運営に転移学習すべき重要な発想だ。一度決めたルールや制度を、放置していないだろうか。人事評価制度、報酬制度、育成プログラム。これらはすべて、検証の仕組みがなければ「組織的負債」として蓄積されていく。

組織運営における最適化の失敗

目的関数なき最適化の悲劇

最近、とある人事系の方々と、AI を活用した組織変革について議論する機会があった。皆さん、真剣に「AI で人事を変えたい」と考えていた。採用の効率化、育成の個別最適化、評価の公平性向上。これから取り組んでいきたいというテーマが次々と出てきた。

しかし、私はある点がずっと気になっており、せっかく経験豊富な人事のプロの方々と議論できるため、思い切って気になっていたことを質問してみた。

「ところで前提として、人事として全体で何を最適化しようとしているのでしょうか？」

やはり難しい質問であったようだ。ここは全体で何を最適化するのか決められていないのが現状だと回答をいただいた。

最適化の第一歩は、何を最適化するかを明確にすること。つまり、世界を閉じることから始まる。

採用は採用で頑張っている。育成は育成で工夫している。評価は評価で改善している。でも、それらを統合した時に、組織全体として何を目指しているのか、誰も答えられなかった。

オペレーションでカバーという幻想

問題は全体として最適化する目的関数が設定されていないだけではない。多くの人事施策が「日々のオペレーションでカバー」されているという現実だ。制度に不備があっても、現場マネージャーの頑張りでなんとかなる。ルールが曖昧でも、ベテラン社員の経験でカバーする。

新しい人事の制度を設計して運用し始めたときは気分が良い。現状での問題に対処した制度であるため、多くの人にとってより良いものになることが間違いない。だからその効果を検証することを甘く考える。

そして、問題が起きるのはその後だ。よくルールが形骸化するという言葉がある。新しく制度を整備しようとしたときに、過去の制度と整合性が取れなくなっている。主張に一貫性がないのだ。しかし、検証可能にしていないため、どこに問題が生じているのかに気づけないのだ。

致命的な問題は潜在的な問題の時点で気づけないことだ。

本番環境で稼働しているアプリケーションにおいて、顧客からバグの報告をもとに修正するのでは遅く、信頼が失われるというのは理解できるはずだ。だからこそ開発者は、テストによって自動的に検証可能にすることで、開発環境での潜在的な問題のうちに解決している。

この考えがユーザーとしては理解できる一方で、組織運営においてはなぜか「オペレーションでカバー」という幻想が存在する。この話をすると施策を新しく講じる前に全ての施策で検証すれば良いという意見も出るだろう。確かに、組織が小さいうちは私も頭の中で完結させて辻褄を合わせることができた。

しかし、組織が大きくなり、施策が増え、担当者も変わり、オペレーションが複雑化してくると、「オペレーションでカバー」という幻想は崩れ去る。属人的なオペレーションは、組織的負債の温床なのだ。

エンジニアリングとの決定的な違い

エンジニアリングの世界でも人力でカバーすることはもちろん存在する。一方で、前述したテストに落とし込むことでなるべく人力に頼らずとも検証可能にする習慣がある。

なぜなら過去の経験則から人力で機能をカバーすることは、開発の時間経過とともに指数関数的にテストしなければならない工数が増えることを知っているからだ。

エンジニアリングの世界では、「世界を閉じることによる短期的最適化」と「自動検証による長期的最適化」が当たり前の習慣として根付いている。

この 2 段階の最適化プロセスこそ、エンジニアリングから組織運営に転移学習すべき最重要の知恵だ。組織運営における最適化の失敗は、この習慣がないことに起因する。だからこそ、この考え方を組織運営に適用することで、真の最適化を実現できると確信している。

AI 時代の革命：世界を閉じられる領域の拡大

LLMがもたらした可能性の爆発

ここまで読んで、「理想論はわかるが、現実的には難しい」と感じた方も多いだろう。確かに、組織という複雑なシステムを「閉じる」のは、プログラムを書くよりはるかに難しい。エンジニアがその世界を閉じられる理由はコンピュータの中で閉じやすい領域だからである。

しかし、状況は劇的に変わりつつある。大規模言語モデル（LLM）の登場により、「閉じられる世界」が飛躍的に拡大したのだ。

従来、形式化（世界を閉じること）ができたのは次のような要素だった。

• 数値データ
• 明確なルール
• 構造化された情報

しかし今、LLM により、次のようなより複雑な要素も計算可能になった。

• 自然言語の文章
• 会話の文脈
• 暗黙的な知識
• 感情や雰囲気

つまり、今まで「測定できない」「数値化できない」と諦めていた要素も、ある程度は扱えるようになったのだ。

しかし、AI は新しい世界を閉じることはできない

ここで重要な事実がある。LLMがどれだけ賢くても、新しい世界を「閉じる」ことはできない。

それはなぜか。LLM は既存のテキストから学習している。つまり、誰かが既に「閉じた」世界の集大成なのだ。あなたの会社独自の文化、あなたのチーム特有の強み、あなたの業界の未来。これらを「どう閉じるか」は、人間にしか決められない。

近いうちにこの固有の世界を閉じる作業自体も AI が可能にするかもしれない。しかし、現時点では人間の創造力が必要だ。AI はあくまで「計算する」存在であり、「閉じる」ことはできない。

世界モデルの設計者という新しい役割

AI 研究の分野では、「世界モデル」という概念が注目されている。現実世界を計算可能な形で表現したものだ。そして今、あらゆる分野で「世界モデルの設計者」が求められている。

これは、エンジニアの専売特許ではない。

• マーケターは、顧客行動の世界モデルを設計する
• 人事は、組織と人材の世界モデルを設計する
• 経営者は、ビジネス全体の世界モデルを設計する

そして、設計された世界モデルの上で、AI が計算し、最適化し、予測する。

これが、人間と AI の新しい協働の形だと私は考えている。

次回予告：どう実践するか

ここまで、なぜ「世界を閉じる」技術が重要なのか、その概念的な理解を深めてきた。

エンジニアが当たり前にやっていることが、実は普遍的な価値を持つこと。組織的負債という見えない脅威があること。そして、AI 時代だからこそ、この技術が全人類に必要になること。

しかし、「理論はわかったが、具体的にどうすればいいのか」という疑問を持つ方も多いだろう。

次回の後編では、実際に組織を「閉じる」具体的な方法を、私自身の失敗と学びを通じて解説する。

• 創業の想いがなぜ消えていくのか、その構造的問題
• 優秀な社員の善意が組織を蝕む副業制度の悲劇
• ソフトウェア開発の CI/CD を組織運営に転移学習する方法
• Policy as Code という組織運営の新たな可能性
• 手間をかけることの価値と長期的思考への転換
• 明日から始められる小さな一歩

エンジニアリングの世界で培われた「世界を閉じて最適化する」という知恵は、決してエンジニアだけのものではない。むしろ、これからの時代は、すべての人がこの最適化の思考法を身につけることで、より良い組織、より良い社会を作っていけるはずだ。

「世界を閉じる」技術を身につけ、AI と真に協働できる人材となる。それが、これからの時代を生き抜く鍵となるだろう。

次回、その具体的な方法を共に学んでいこう。

▶︎ AI 時代に「世界を閉じる技術」が価値を持つ（後編）

関連記事

この記事について共感いただけたなら、次はこれらの記事で更なる視点を得てほしい。

• AI時代に「世界を閉じる技術」が価値を持つ（後編）：本記事の実践編。Policy as Code という組織運営への具体的な実装方法を、失敗談を交えて解説。
• ボーナス制度の罠：組織に残す見えない負債の構造的問題：本記事で引用した実例。短期的成功が長期的失敗を生む組織的負債の構造を詳細に分析。
• Memory Bankで実現する効率的なAI協働の開発ガイド：「世界を閉じる」技術の実践例。文脈を構造化し検証可能にする具体的手法。
• テスト駆動開発の進化形：AI協働開発におけるテストトロフィー戦略：検証可能性をテストで実現。長期的最適化の技術的実装。
• 成果物を超えたプロセス評価の真価：プロセスの形式化と検証の重要性。第三者視点での品質保証の本質。

これらの記事はすべて、無限を有限に変換し、検証可能にするという思想で貫かれている。理論から実践へ、段階的に理解を深めてほしい。