出発点は、ソフトウェアのコストが下がったことである
五本目に、こう書いた。
AI革命とは、このソフト部分のコストを一気にゼロに近づけた出来事である。
そこから自給を導いた。だが、攻撃もソフトウェアである。検証もソフトウェアである。 一つの変化から、三つのことが同時に起きる。
誰でも作れる。 これが自給であり、五本目の主題だった。
誰でも攻撃できる。 攻撃の最も時間のかかる工程──対象の構造を読み解くこと──をAIが肩代わりする。配られた重みは回収できない。そして作る人が増えれば、的の数も増える。数が増えれば、いつかは当たる。少なければ運で逃げ切れるが、多ければ運は尽きる。しかも、速い。
誰でも検証できる。 これが後述する第二条件の前提になる。
五本目は、この一つ目だけを書いた記事だった。二つ目は、同じ原因から同じ日に出ている。
安くなった攻撃は、集中しているところに当たる
では、安くなった攻撃はどこを攻撃するのか。集中しているところである。
一つのシステムに全部が乗っていれば、一つの穴で全部が出る。同じベンダーの同じ構成が百社に入っていれば、一つの脆弱性で百社が落ちる。判断が中央にあれば、中央が答えるまで現場は止まる。攻撃する側から見れば、集中とは一回の成功で得られるものが大きい場所のことだ。
これは新しい話ではない。四本目に書いたとおり、攻撃のコストが劇的に下がった時代に、集中は資産ではなく標的である。集中は前からあり、危険も前からあった。ただ攻撃が高価なあいだは、支払いを延ばせただけである。
AIは、防御にも使える
ここで悲観に傾く必要はない。攻撃を安くしたのと同じ変化が、防御も安くしている。
以前の記事に、こう書いた。
攻撃とは、システムの構造を、その設計者以上に深く理解し、弱点を見つけて突くことである。構造をそこまで深く理解できる力は、そのまま、設計する力であり、検証する力でもある。攻撃・設計・検証は、別々の能力ではない。「構造を深く理解する」という、一つの力の、三つの顔にすぎない。
攻撃を安くした力は、検証も安くする。仕様書の欠陥も、契約の空白も、自社システムの弱点も、AIに読ませれば数時間で見える。かつて外部の専門家に頼んで数週間かかったことが、手元で回るようになった。
つまり道具は、両側にある。差がつくのは道具の有無ではなく、それが誰の手元で回っているかである。
そしてもう一つ、この議論が置いていた前提がある。防御の道具が、これからも安いことだ。それを裏づけたのがKimi K3である。総パラメータ2.8兆のフロンティア級が、オープンウェイトで配られる。
意味は価格の側にある。同等の能力が無償で手に入るなら、商用モデルの価格には天井がつく。そして配られた重みは回収できない。防御に使う道具が、この先で高くなる筋道は消えた。 検証の道具だけが高くなれば、安い道具を持つのは攻撃側だけになり、非対称は元に戻る。そうはならない、と言える材料が出た。
そして、この先も見えている。AIが人間より賢くなれば、攻撃と防御は同等になり、そこで安定する。
攻撃が守りより有利だったのは、攻める側は一つの穴を見つければよく、守る側は全部を塞がなければならないからだ。だがこの非対称には、二つの原因が重なっている。
一つは、守る側の手が足りないこと。全部を見るには人手が足りず、だから見落とす。これは検証が無料になれば消える。
もう一つは、構造だ。全部が繋がっていれば、一つの見落としが全部の損失になる。こちらは検証をいくら安くしても消えない。穴を多く見つけられるようになっても、一つ漏らせば同じだからである。
つまり均衡は、検証が安くなるだけでは来ない。検証が安く、かつ一撃で倒れる範囲が小さいときに来る。
そしてその均衡は、攻撃がなくなった状態ではない。ときどき攻撃され、被害も出て、それでも業務が続く状態である。 火事や盗難と同じ扱いになる、ということだ。無傷ではなく、倒れないこと──目標はそこに移る。
後者は、たいていの会社には手が届く。全部と繋がっていなければならない理由が、ふつうの会社にはないからだ。
問題は、その理由がある者である。恐ろしいのは均衡そのものではない。そこへ移れない者が出ることだ。
そして、ここで委託が問題になる。委託とは、守る判断を社外の一点へ集中させる形である。 しかも、置ける中で最も遠い一点だ。
委託には往復が組み込まれている。検知し、窓口へ連絡し、受け付けられ、調査され、方針が返り、承認して実施する。各段で数時間から数日が飛ぶ。他社に頼むという形が、必然的に持つ時間である。速度は、この往復を追い越す。量は、この往復を詰まらせる。 委託先の容量は件数で見積もられ、しかも他社と共有されている。攻撃は行儀よく間隔を空けては来ない。
検証をほぼ無料にする道具が手元にあるのに、その判断を最も遠い一点へ送り続ける。それが、いまの形である。
だから、自立する ── 組織として責任をもつ
委託が間に合わないなら、組織が自分で引き受けるしかない。だが「自立」は、たいてい誤解される。新しい負担を背負う話に聞こえるからだ。実際は逆である。
いま多くの組織が買っているのは、システムだけではない。何かあったときに「ベンダーの責任です」と言える体制を一緒に買っている。だが、それは成立していない。契約には責任上限があり、たいていは支払った額の範囲に収まる。信用を失うのも、業務が止まって損をするのも、顧客に説明するのも自社である。責任は最初から移っていない。移っていたのは作業だけだ。 混同してきたから、責任を負ったまま、それを扱う能力だけを手放していた。最も悪い形である。
だから自立とは、新しい責任を負うことではない。すでに負っている責任を、扱えるようにすることだ。 負担は増えず、増えるのは扱えるという事実だけである。そしてそれが、五本目に書いたとおり、取引の資格になり、事業継続の条件になる。
Microsoftのパラドックス
責任を引き受けると決めても、次の壁が来る。そしてその壁は、いちばん大きなところに、いちばんはっきり出ている。
互換性はMicrosoftの強みだった。何十年も前に書かれたものが、今日も動く。それが選ばれてきた理由である。だがそのままにすれば、AIによる攻撃に耐えられない。切れば、顧客が離れる。守ると約束したものが、守りを妨げている。
SIerも同じ壁の前にいる。資産は、納品済みのシステムとその保守契約だ。保守をAIができるなら、保守料の根拠は消える。できないなら人がやることになるが、人件費はAIより桁違いに高く、それでいて精度は落ちる。どちらに転んでも、いまの保守料は説明がつかない。
そして中小企業に納品されているシステムなら、AIが読めないものはまずない。分岐は実質ひとつで、答えはもう出ている。 確かめるのに要るのは、納品物をAIにかける半日だけだ。
根はもっと深い。中小企業の業務は、COBOLやVBで足りていた。 受注を記録し、在庫を引き当て、請求書を出す──処理の中身は三十年前から変わっていない。それでもシステムは何度も書き直され、そのたびに層が増え、社内で説明できる人はいなくなった。書き直しは、発注側にとっては費用で、受注側にとっては売上である。悪意を疑う必要はない。構造がそうなっていた。
そして書き直しを正当化してきた最大の理由は「その言語をやれる人がもういない」だった。その理由は、いま消えた。AIはCOBOLもVBも読む。
代わりの契約形態が用意されているわけでもない。根拠を失った支払いは、別の名前に置き換わるのではなく、無くなる。
構造を作り替えるのは、もう難しくない
ここまで読んで、構造の作り替えを大工事だと思ったかもしれない。かつては、そうだった。作り替えなかったのは怠慢ではない。高かったからである。
その費用が落ちた。現状のシステムを読み、依存を洗い出し、区画の候補を出し、移行の手順を書く──それはいま、AIがやる仕事である。本稿の出発点であるソフトのコスト低下は、攻撃と検証だけでなく、作り替えにも同じように効く。
妨げているのは、前節の形に乗っていることだ。攻撃に弱いと分かっていても、Windowsも、M365も、納品済みの基幹システムも、来週には消えない。当面の課題は、それらを閉じ込めることである。
閉じ込めるとは、その製品と繋がる範囲を最小限に限定することだ。区画の中に置く。認証を分け、そこが破られても他が生き残るようにする。止まっても業務が続く経路を、別に持つ。そして新しいものを、その上に足さない。
具体で言えば、こうなる。文書を作るのに必要なのはWordとExcelであって、Microsoft 365ではない。買い切り版で足りる。それでも契約が続くのは、電子メールとファイル共有のためだ。 そしてその二つが、認証を一つに束ねている。アカウントが一つ破られれば、文書もメールも共有ファイルも同時に出る。集中とは、この形のことである。
だから順序が決まる。文書は、外に繋がらない形へ戻せる。ファイル共有は、もっと単純な構造でいい。 階層とグループとリンク共有が絡み合った仕組みは、社内の誰にも説明できない。説明できないものは、守れない。 単純なディレクトリと単純な権限なら、説明できる。メールは、届ける工程だけを外に出せば、郵便受けもアカウントも自社に置ける。
これは妥協ではない。外せないものに対してできるのは、外すことではなく、一回の成功で得られるものを小さくすることだ。
守れるかどうかは、担当者の優秀さより、構造の形で決まる部分が大きい。 ここを人の努力の問題として扱うと、必ず失敗する。
そのために、守れる人が要る
責任を引き受け、構造を作り替える。それを回すには、人が要る。
ただし、最も流通している助言を先に潰しておく必要がある。
AI時代に生き残るには、AIに奪われない深い専門を持て。たとえばセキュリティのような。
これは構造を誤読している。AIが吸収しているのはソフトウェアエンジニアリングという層の全体であって、その中の特定分野ではない。専門を深めることは、その専門が追い越される日付をずらすだけだ。中世に置き換えれば、農奴に「もっと専門的な農奴になれば自由になれる」と助言しているのと同じ形になる。
必要なのは、三つである。
第一条件:自分が作ったものの構造を理解していること
先に引いた「攻撃・設計・検証は、一つの力の三つの顔にすぎない」を、道具の側から人の側へ移すと、答えが変わる。攻撃に対応できる人とは、防御の専門家ではない。自分が作ったものの構造を理解している人である。 そして構造を理解している人は、同じ理由で設計もでき、検証もできる。
先例は品質保証だ。かつては検査部門の仕事だった。それが「作る人全員の条件」になったとき、品質は部署の名前ではなくなった。守ることも同じ経路を通る。専門職として分離されている状態は過渡期であって、完成形ではない。
そしてもう一点。これは最高の価値ではなく、最低の参加資格である。 価値を生むのは判断であり、素材であり、作ったものそのものだ。だが、どれほど優れた判断をしても、一度の侵入で全部が飛ぶ。だから第一なのであって、最重要だから第一なのではない。床であって、天井ではない。
第二条件:先端のAIで、自分で確かめられること
二つ目は、いちばん単純だ。手元の先端AIに自分の仕事をかけて、確かめられること。 それだけでいい。何年もの専門教育は要らない。検証に必要なのは大量のコードを書く力ではなく、自社のシステムをかけ、出てきた指摘を読み、どれが本当に危険かを判断する力である。
ただし、外してはいけない点が二つある。
一つは「先端の」という部分だ。 道具の質が、検証の質の上限を決める。弱いモデルで確かめれば、弱い確認しか返らない。そして厄介なことに、弱い確認は「確かめた」という感触だけは残す。ベンダーが製品に同梱してきたAIで済ませると、たいていここに落ちる。月額数千円で最上位が使える時代に、そこを節約する理由はない。
もう一つは「自分で」という部分だ。 誰かに検証させて報告を受け取るのは、検証したのではなく、検証を外注したのである。しかもそれは「往復」をもう一度作ることでもある。出てきた指摘を自分で読み、どれが本当に危険かを決める。
読ませる材料も、自分で選んだほうがいい。自社の設計判断の記録、公式の規格、一次資料。渡すものが自分のものであるほど、返ってくるものは世間の平均から離れる。まず、確かめること。
第三条件:端で決められること
委託の往復が間に合わないのと同じ理由で、組織の内部の往復も間に合わない。 情報は全部集まっている。AIも導入済みだ。それでも、決裁が中央へ行って戻るまでに事象が終わるなら、端のセンサーは飾りになる。上海が662か所の雨量観測点を持ちながら水に浸かったのは、この形である。センサーは足りていた。平均が局所を消し、判断が中央にあった。
だから三つ目の条件は、手元の情報で、事象の速度に間に合う速さで、自分で決められることだ。そしてこれは個人の資質であると同時に、組織が個人にそれを許しているかという問題でもある。ここで話は、構造の節へ戻る。
いま流通しているもう一つの物語は、この逆を勧める。判断をAIに、プラットフォームに、あるいは一人の指導者に集約せよ、と。だが統計処理の道具は、判断も責任も負えない。
整理すると、三つの層になる
| 層 | 問い | 手放さないもの |
|---|---|---|
| 組織の意思 | 誰が結果を引き受けるか | 責任 |
| 組織の構造 | 一撃でどこまで倒れるか | 分かれていること |
| 人 | 誰が理解し、確かめ、決めるか | 理解・検証・判断 |
この三つは、別々の要求ではない。同じ一つの行為を、三つの縮尺で見たものである。 責任を引き受け、それを社内へ配り、配った先に人が立つ。上から下へ、一本の線で繋がっている。
観測点
責任。 取引条件にセキュリティ要件が入る案件の比率。事故を公表する主体が、発注元になるか受注先になるか。
構造。 一つの侵害で同時に落ちる企業数。侵害が起きたとき、止まった業務の割合。
移れるかどうか。 大手ベンダーが、互換性を切ってでも構造を作り替える決断をするか。保守契約の単価と更新率が下がり始めるか。
人。 自社システムの構成を社内で説明できる企業の比率。従業員が先端モデルに日常的に触れられる企業の比率。
そして本稿が外れる条件も書いておく。保守料が根拠を問われないまま維持され、集中したシステムが破られないまま推移した場合、この論は成り立たない。外れたら、外れたと書く。
関連
本稿は「ゼロトラスト」三部作の完結編であり、五部作の帰結でもある。
- ブログ Fable 5 が戻ってきたら、すぐやるべきこと ── 稼働中システムを、全部検証する ── 第二条件の実務版。「攻撃・設計・検証は一つの力の三つの顔」の初出
- ブログ AIは無知だから間違えるのではない ── ある誤答から考える、AIとの付き合い方 ── 使う側のゼロトラスト。なぜ「何を読ませるか」が効くのか
- ブログ Kimi K3 は何から作られたのか ── 作る側にも、ゼロトラストを ── 作る側のゼロトラスト。検証を通ったものだけを相続する工学
- ブログ ITという産業が終わり、素材と組立の時代が始まる ── 五部作の最終回。本稿が塞ぐ穴を開けた記事
- ブログ 同じ週に、三つの決着が近づいている ── 上海の662か所と「判断の配置」
- ブログ 自律・分散・多様 ── これからのシステムの形 ── 構造の層の設計論版
- ブログ 社内業務システムは、もう外注するものではない ── 委託から自給への実務
- ブログ ソフトウェアの三つの転換 ── 「特化したエンジニアになれ」という助言への構造的応答
参考
- 本連載五部作(K3重み公開の注目点/AI企業の現実とK3/Microsoft 7月29日決算/ウクライナ・イラン・中国の現状/ITという産業の終わり)── 一本目は https://aiseed.dev/blog/kimi-k3-what-to-watch/
- 上海の記録的豪雨(2026年7月19日、楊浦区五角場で1時間104.5ミリ・4時間半212.8ミリ、全市平均29.7ミリ)── 中国安全情報局 https://www.alertchina.com/post-35388/
- Kimi K3 Open Weights Drop July 27: The Developer Prep Guide(byteiota)── オープンウェイトの配布と回収不能性 ── https://byteiota.com/kimi-k3-open-weights-july-27-developer-prep/