Blog
Mythos公開まで半年〜1年。対応は緊急——自らスキャンし修正できる環境を今すぐ整える。
2026年4月、画期的な道具が2つ揃った。
Anthropicが「Project Glasswing」を通じて、最新モデル「Claude Mythos Preview」の限定公開を発表したのは、2026年4月7日（米国時間）である。 このリリースは、AIの歴史においても非常に特異なものだった。公式発表の背景には以下のような事実がある。
Gemma 4は、Mythosに先立ち2026年4月2日にGoogleが完全なオープンソース（Apache 2.0ライセンス）として公開した高効率・高性能モデルである。 その本質は、最高峰の推論能力を、手元のオフライン環境で使えることにある。
機密性の完全担保（ゼロ・リーク）: 外部のクラウドと一切通信しないため、個人情報や未公開の財務データ、行政の機密情報も安全に処理できる。
圧倒的な軽さと速さ: メモリ消費を極限まで抑えた設計（MoEアーキテクチャなど）により、ローカルPC上でも一瞬にしてテキストのパースやコードの検証を完了させる。
CLI特化の実用性: エージェントのようなブラックボックスを排し、ターミナルから直接テキストを流し込んで処理させる「パイプライン（Unix的アプローチ）」の部品として完璧に機能する。
事態の深刻さを示す決定的な出来事が起きた。「Project Glasswing」が発表された同日、米財務省とFRBの指導者らがワシントンの財務省本部にウォール街大手銀行のトップを緊急招集し、Anthropicの最新モデル「Claude Mythos Preview」が引き起こしうる壊滅的なサイバーセキュリティリスクについて直接の警告を行った。
Anthropicは、Mythosの提供を初期パートナー12社と40超のインフラ組織に限定する措置を取ったが、これは一時的な防波堤に過ぎない。選ばれたインフラ群の脆弱性修正が完了すれば、Mythosは必ず一般公開される。その瞬間、防御側だけでなく攻撃側も全く同じ能力を手にすることになる。Glasswingの枠外にある組織にとって、システムが陥落し始めるまでの猶予（カウントダウン）は、わずか半年から1年しかない。
このカウントダウンにおいて最も致命的なリスクとなるのが、WindowsやOfficeといった数十年分のレガシーコードを抱えるシステムへの依存だ。これらは内部がブラックボックス化しており、Mythosによるスキャンが始まれば、修正すべき脆弱性が膨大すぎて一般公開までにパッチが間に合わない。さらに、Microsoftが推進する「Copilotエージェントによる自動化」も、プロンプトインジェクションへの脆弱性やデータ主権の喪失といった構造的欠陥を抱えており、Mythosの攻撃能力の前では巨大な侵入口と化す。
つまり、自組織のセキュリティを巨大ベンダーの脆弱なエコシステムに委ね続けることは、公開後も長期間にわたり「未修正の攻撃面の上で無防備に仕事をする」ことを意味する。
Glasswingの保護枠外にある組織にとって、Mythosの一般公開は待ったなしの脅威である。公開と同時に、自らの手でシステムをスキャンし、即座に脆弱性を修正できる環境を整えておかなければならない。Mythosのコード解析・防衛能力はすでに人間のセキュリティ専門家を凌駕しているため、この作業を外部ベンダーへ委託することは致命的なタイムロスとなる。現行の Claude（Opus 4.6、Sonnet 4.6 等）の能力を用いれば、自力でこの防衛環境を構築することは決して難しい作業ではない。以下に、3つの領域において直ちに着手すべき移行プロセスを示す。
現在のオフィス環境は、WindowsとOffice製品という「ブラックボックス」に支配されている。ExcelやWordなどのバイナリファイルは Git による差分管理ができず、「誰が・いつ・なぜ変更したか」という履歴が個人の頭の中にしか残らない。加えて、数式やマクロの調整といった非創造的な手作業に膨大な時間を奪われている。さらに深刻なのは、ファイルを開くだけで感染するゼロデイ脆弱性や、Windows、Entra ID、Azureが密結合したエコシステム特有の連鎖的リスクである。ここに Copilot が統合されることで、攻撃面はかつてない規模に拡大している。
この危機を脱するには、デスクトップ環境をWindowsからLinuxへと移行させることが最善手となる。業務ドキュメントは Markdown、CSV、JSON 等のプレーンテキストへ変換し、すべて Git で管理する「Doc as Code」を徹底する。従来のExcel業務は、手順を観察してロジックを抽出し、Claude に Python 等のコードへ書き換えさせる。機密情報を含む定型処理は、常駐型の Copilot 等に任せるのではなく、ローカルの Gemma 4 を CLI で単発実行して処理を完結させるべきである。
社内システム（旧来のERP、Access、オンプレミスアプリ）の多くは、SIer が納品した中身の分からないブラックボックスと化している。内部構造を把握している社員はおらず、脆弱性が発見されてもベンダーへの再依頼から修正まで数週間から数ヶ月を要する。外部 API 連携や VPN 越しのアクセス経路も残り、「イントラネットだから安全」という前提はすでに崩れている——VPN 機器自体が攻撃対象になり、Mythos 公開後はここからの侵入が加速する。また、昨今は「効率化」の名の下にAIエージェントを内部システムに組み込む動きがあるが、これは外部からの攻撃経路（プロンプトインジェクション等）を増やすだけの愚策である。
求められるのは、SIerへの依存を断ち切り、自分たちと Claude の対話によってシステムをオープンな形で建て直すことだ。AIの支援を受ければ、旧来のシステムも短期間でモダンなコードに置き換えられる。自動化するのは「人間が承認した決定論的ロジック（Python、SQL、シェルスクリプト）」のみとし、システム内部でAIエージェントを自律的に常駐・判断させてはならない。データは手元の SQLite でシンプルに管理し、中央DBへの依存を最小限に抑える。ソースコードを手元で Git 管理し、すべての構造を自己把握しておけば、Mythos が未知の脆弱性を突いてきても、自らの手で即座にパッチを当てることができる。イントラネットも公開システムと同等の防御を前提に設計する。
Webサイトにおける最大の脆弱性は、WordPress などの CMS とそれに付随するデータベースの存在である。プラグインの脆弱性や認証不要の悪用経路は絶えず、WAF（Web Application Firewall）を導入しても高度な攻撃の大部分は素通しされてしまう。近年流行している公開システムへのAIチャットボットやAI検索の統合も、攻撃の的を増やす行為に過ぎない。
これに対する唯一の正解は、「攻撃面を物理的にゼロにする」ことだ。CMSや動的データベースを本番環境から完全に破棄し、Markdown とビルドツールを用いて生成した「静的な HTML」のみを配信する。サーバー構成は Linux と Nginx に静的ファイルを置くだけの極限までシンプルなものとし、「1サーバーにつき1アプリ」の疎結合を徹底する。当然、本番環境へのAI組み込みも全廃する。Mythos にスキャンされても「攻撃すべき動的要素が何一つ見つからない」状態を作ることこそが、これからの時代における最強の防衛策である。
注文や問い合わせの処理システムのような情報を受け取る部分は、以下のような設計が最適解である。
1. 「一方向のバルブ（Write-Only API）」として設計する
注文や問い合わせの処理システムを、Webサイト（静的HTML）の中に同居させてはならない。入力処理のためだけの独立した小さなAPIサーバーを立てる。
2. 「決定論的バリデーション」の徹底
この受信用APIが攻撃の標的になるが、CMSのような巨大なアタックサーフェスとは次元が異なる。
3. 非同期処理とローカルAI（Gemma 4）への連携
受け取ったデータは、Webに面したサーバー上に長く留めておくべきではない。
業務におけるAI利用の核心は、「効率化の名を借りた責任の放棄」を防ぐことにある。
第１原則：自律型エージェントの完全排除（非自律の原則） 業務において、AIに「自ら判断し、自らシステムを操作する」権限（自律型エージェント機能）を絶対に与えてはならない。AIの役割は、乱雑なデータの整理やコードの草案作成といった「翻訳と可視化」に限定する。データの書き換え、外部への送信、システムの変更といった最終的な実行機能は、AIの手の届かない場所に物理的に隔離しなければならない。
第２原則：責任の局所化と人間の絶対優位（決定の原則） 自律型AIに業務の進行を委ねることは、結果に対する責任の所在をブラックボックス化し、組織のガバナンスを崩壊させる。AIは高度に「もっともらしい予測」を行う機械に過ぎず、ビジネス上のリスクや倫理を伴う「決定」を下すことはできない。AIが生成したドラフトや解析結果を人間が確認し、「自らの意志で承認（Enterキーを押す等）」するプロセスを必ず挟むことで、業務の最終的な説明責任（アカウンタビリティ）を人間が100%保持し続ける。
第３原則：ブラックボックスの拒絶と防衛（脆弱性排除の原則） 自律型AIが内部で繰り返す見えない推論ループや、Copilotのような外部の巨大エコシステムとの密結合は、システムに制御不能な脆弱性（プロンプトインジェクションやデータ漏洩）をもたらす。これを防ぐため、AIの利用は「入出力が完全に追跡可能なパイプライン（CLIなど）」に限定する。AIの出力結果は必ずプレーンテキスト（Markdownやソースコード）で出力させ、Git等で変更履歴を物理的に記録することで、常に人間が監査・修正できる状態を維持する。
第４原則：決定論的自動化への回帰（実行の原則） AIが介入してよいのは、人間の「曖昧な意図」をロジックへと変換するフェーズのみである。人間が一度「正解」として承認した処理手順は、即座にAIから切り離し、100％の再現性を持つ「決定論的なコード（PythonやSQLなど）」として固定する。固定された定型処理にはAI（確率論）の入り込む余地を与えず、バグのない機械的な自動化として運用する。
公開までの時間は半年〜1年。今日始めなければ、間に合わない。
自ら考え、自らコードを書き、自ら決定を下すビルダーの精神を取り戻す。コードはAIが書いても問題はない。その結果に責任を持つということだ。
Linux PC を使うことから始めよう。
コメント・議論は Facebook グループへ：AISeed — 生物多様性・食料・AIと暮らし