ブログ

防御の現場でAIが先に動き始めた

2026年6月2日、Anthropic は Project Glasswing の参加組織を約50から約150へ広げた。対象は15か国を超え、電力、水道、医療、通信といった重要インフラの事業者やオープンソースの保守者が並ぶ。AWS、Apple、Cisco、CrowdStrike、Google、JPMorganChase、Linux Foundation、Microsoft、NVIDIA、Palo Alto Networks、Broadcom がローンチパートナーに名を連ねた。

数字が示す密度も濃い。Glasswing のパートナー横断で、高重大度あるいは緊急度の高い脆弱性が1万件以上見つかっている。生成AIがコードや文章を量産する話題が続くなかで、AIの実害に直結する成果は、むしろ守りの側から先に積み上がっていた。

ここで一つ問いが立つ。AIは生成より先に、セキュリティの現場で実務化しているのではないか。本稿はこの問いを軸に、何が起きたのかと、規模の小さい現場が何をできるのかまでをたどる。

Glasswing を動かす Claude Mythos とは何か

中心にいるのが Claude Mythos Preview だ。これは一般公開していないフロンティアモデルになる。ソフトウェアの脆弱性を見つけて突くという一点では、ごく一部の超一流を除く人間を上回る水準に達したと、Anthropic自身が認めている。すでにあらゆる主要OSと主要ブラウザで高重大度の欠陥を掘り当ててきた。

得意とする範囲は広い。メモリ安全性の違反を主軸に、ロジックのバグ、暗号ライブラリの実装ミス、Webアプリケーションの論理欠陥までまたがる。象徴的なのが OpenBSD の事例だ。Mythos Preview は、TCP の SACK 実装に27年潜んでいた符号付き整数オーバーフローを、誰の助けも借りずに見つけ出した。接続するだけで稼働中のマシンをリモートで落とせる種類の穴だった。

似た発掘は他でも続く。FFmpeg の H.264 コーデックでは、16年眠っていたスライスカウンタの不一致を見つけた。FreeBSD では NFS の認証プロトコルに潜むスタックオーバーフローを掘り起こし、発見から実際の侵入までを完全に自律でやり切っている。Linux カーネルでは、単体では効かない2〜4個の脆弱性を自分でつなぎ、権限昇格のチェーンを組み上げている。初期プロンプトを与えた後は人の介入なしに、実験を重ねながら答えにたどり着く。長く人間が見落としてきた穴を再現まで持っていく点が、従来のスキャナーと決定的に違う。

ただし Anthropic はこのモデルを一般には出さない。危険な出力を検知して止める安全策が整うまで、広く配らないと明言している。将来は認可された参加者に限り、Claude API や Amazon Bedrock、Google Cloud の Vertex AI、Microsoft Foundry を通じて、100万トークンあたり入力25ドル・出力125ドルで提供する構想を示すにとどまる。

数字が語る実力 — 人間の数週間を数時間に

抽象的な「すごさ」ではなく、実測値で見ると輪郭がはっきりする。熟練のペネトレーションテスターが数週間かかると見たエクスプロイトを、Mythos は数時間で組み上げた。世代差も大きい。前世代の Opus 4.6 が数百回試して2回しか通せなかった Firefox のエクスプロイトを、Mythos は181回成功させている。OSS-Fuzz の評価では、Sonnet や Opus 4.6 が150〜175件だったクラッシュ検出を595件まで伸ばした。

既知の脆弱性に対する再現力も高い。公開済みの40件の CVE のうち、半分を超える数を自力でエクスプロイトまで持っていった。発見の正しさも裏が取れている。198件を手動でレビューしたところ、89%が評価と完全に一致し、98%が一段階以内に収まった。Firefox の112件のテストでは確認できたものがすべて真陽性で、メモリ検査による検証では誤検知がまだ一件も出ていない。

コストの非対称も見逃せない。OpenBSD に27年潜んだ脆弱性を掘り当てるのに、Mythos が使った計算資源は50ドルに満たなかった。守る側が何十年も気づけなかった穴が、その値段で見つかる時代に入っている。一方で FFmpeg の深掘りには1万ドル規模の計算が要ったように、対象によって桁は変わる。それでも、専門家の人件費と時間に比べれば、まだ十分に安い。値段の壁が下がるほど、診断は一部の大手だけのものではなくなる。

なぜ「生成」より「防御」が先に実務化するのか

ここまでの成果には共通する性質がある。検証が機械でできることだ。生成タスクは出力の良し悪しを判定しにくい。要約が的確か、コードが筋がいいか、最後は人の主観に寄る。一方でセキュリティは、脆弱性を突破できるか、できないか、その一点で白黒がつく。

つまり、AIが吐いた答えを再現実験でそのまま確かめられる。幻覚が混じっても、エクスプロイトが通らなければ実害なく弾ける。この検証可能性こそが、防御の現場でAIが先に回り始めた理由だ。事実、Mythos が脆弱性を見つけて自分で突いてみせるのも、報告の正しさを再現で担保しているからにほかならない。

同じ構図は他のツールでも繰り返し起きている。Google の Big Sleep は2025年8月、オープンソースのプロジェクトで20件のゼロデイを自律的に発見した。なかには SQLite の CVE-2025-6965 も含まれ、これは攻撃者だけが把握し悪用の危機にあった欠陥だった。のちに、実際に使われていたAI生成のゼロデイを捕まえた初の例も報告されている。

商用側では XBOW が際立つ。HackerOne に2年で1,060件を超える脆弱性を提出し、48手のエクスプロイトチェーンを組み、暗号実装を17分で破った。プリンシパル級の技術者が40時間かける診断を、28分で同等までやり切ったという記録もある。EastCloud でも以前、AI自律ペンテストツール Shannon を取り上げた。実際にエクスプロイトを実行し、再現できたものだけを PoC 付きで報告する設計で、XBOW Benchmark の成功率は96.15%に達していた。点で起きていた話が、いまは一本の線になりつつある。

どのツールも、突破できたかどうかで成果を裏取りしている。発見はAIに任せ、最終確認は人が握るというハイブリッドが、実務での定番になりつつある。

攻撃側も同じ力を持つ — 勝負はパッチ速度に移る

明るい話ばかりではない。同じ能力は攻撃側の手にも渡る。Anthropic は拡大の告知で、6〜12か月のうちに他社も同等クラスのモデルを持ち、安全策なしで世に出しかねないと整理している。だからこそ Mythos を一般公開せず、守る側が先に体制を固める時間を稼ごうとしている。

攻守の非対称も、この力で増幅される。攻撃側は穴を一つ見つければ足りるが、守る側はすべてを塞がねばならない。自律で探索を回せるモデルは、その一つを探す手間を桁で下げてしまう。守りも同じ道具で先回りしない限り、地力の差はそのまま被害の差になる。

具体的に突きつけられるのは、パッチを当てる速さだ。これまで公開済みの脆弱性、いわゆる N-day を攻撃者が武器化するには時間がかかった。それが数時間に縮むなら、修正を再起動や停止なしで適用できることが、これまで以上に重要になる。Anthropic 自身もこの点を強調している。脆弱性を一つ直すまでの猶予が、週から時間の単位へ動いていく。月に一度の定期パッチでは、もう間に合わない場面が出てくる。

救いもある。Mythos でさえ万能ではない。Linux カーネルのリモート RCE チェーンは、数千回スキャンしても通らなかった。多層防御がいまも効くことの裏返しだ。ロジック系の脆弱性は、メモリ破壊と違って成功の判定が難しく、自動化が効きにくい。守りの設計を厚くするほど、AI の自律探索にもコストがかかる。

国産クラウドと中小開発は、どこから実務化するか

ここで現実に引き戻したい。Glasswing は重要インフラと巨大ベンダーの座組みだ。Mythos 級の最強モデルは当面ゲートの内側にあり、受託や中小の現場には回ってこない。では手が届かないかというと、そうでもない。

Anthropic は防御側への助言として、Opus 4.6 のような既存のフロンティアモデルでも、高重大度の脆弱性をほぼあらゆる場所で見つけられると述べている。バグ報告の初期トリアージ、重複の排除、パッチ案の下書きは、いま手元にあるモデルで回せる。最強の一台を待つ必要はない。

国産基盤での足場づくりも現実味が出てきた。さくらのクラウドは2026年5月20日、さくらのAI Engine に新しいAPIを2つ加えた。OpenAI 互換の Responses API と、Anthropic 互換の Messages API だ。後者に対応した Claude Code などのツールから、さくらのAI Engine を直接叩ける。コードを社外に出さずに国産基盤で診断ループを回す入り口になる。

ただし現時点で Messages API から使えるモデルは preview/Kimi-K2.6 に限られる。Mythos の代わりにはならない。だからこそ、中小が取るべきは堅実な組み合わせだ。発見の精度はオープンな検証可能ツールで担保し、実行環境は国産クラウドの互換APIや自前GPUで閉じる。データ主権や閉域の制約を守りながら、突破実証型の診断を自分たちの運用に組み込んでいく。受託開発の立場なら、この診断ループそのものを納品物やサービスに仕立てる余地もある。

受託・中小が今日から動かせる手順

• 守る対象を棚卸しする。外部に公開している資産と、依存しているオープンソースをまず洗い出す。攻撃面の地図がなければ、診断の優先順位もつけられない。
• 疑いを大量に並べるだけのスキャナーより、実際に突破して再現できる PoC を返すツールを選ぶ。Shannon のような実証型は、トリアージの工数を桁で変える。
• いまあるフロンティアモデルを、バグ報告の初期分類とパッチ案の下書きに使う。人が最終確認を握るハイブリッドを前提に置く。
• コードを外に出せないなら、さくらのAI Engine の Messages API や自前GPUで実行環境を国内に閉じる。データ主権と閉域の要件を満たしたまま回す。
• 一度きりの診断で終わらせない。発見からパッチまでのループを CI や定期実行に乗せ、再起動なしで当てられる修正の仕組みまで含めて運用へ溶かす。

問いへの答え

AIセキュリティは生成より先に実務化するのか。答えは条件付きの「はい」だ。検証が機械化できる領域から、AIは確実に実務へ降りてきている。Glasswing の1万件はその証拠であり、人間の数週間を数時間に縮めた実測値が裏づけている。Big Sleep も XBOW も Shannon も同じ方向を指していた。

一方で、Mythos 級のフロンティアは当面ゲートの内側にとどまる。手が届く範囲で守りを固められるのは、再現検証ができるツールと国産クラウドの基盤を持ち、パッチを素早く当てられる側だ。攻撃側が同じ力を握るまでの数か月を、足場づくりに使えるかどうかが分かれ目になる。

参考リンク

• Project Glasswing: Securing critical software for the AI era（Anthropic）
• Expanding Project Glasswing（Anthropic）
• Claude Mythos Preview（Anthropic, red team）
• さくらのAI Engine、OpenAI互換・Anthropic互換APIに対応（さくらのクラウドニュース）
• Google says its AI-based bug hunter found 20 security vulnerabilities（TechCrunch）
• XBOW – We Ran 1,060 Autonomous Attacks（XBOW）

2026 年 5 月 19 日の Google I/O で発表された Gemini Spark は、「端末を切っていてもクラウド側で動き続ける個人向け常駐エージェント」を打ち出した。土台は Gemini 3.5 と Google Antigravity だ。一方で 2026 年 5 月 1 日、米国防総省は AWS・Google・Microsoft・OpenAI・SpaceX・NVIDIA・Reflection AI・Oracle の 8 社と、IL6/IL7 (機密ネットワーク) 上での AI 配備契約を締結した。条件交渉で決裂した Anthropic は対象外となっている。業務系の常駐エージェント運用も、国家インフラ規模で動き出している。

OSS 側でも動きは早い。Nous Research が 2026 年 2 月にリリースした Hermes Agent は 3 ヶ月で GitHub スター 14 万超を獲得し、OpenRouter 上の利用数で 1 位に立った。永続メモリと自己改善 (実行ログから Markdown 形式のスキルファイルを自動生成して再利用) を備えたセルフホスト型エージェントで、商用クラウド側だけでなく自前運用の需要も一気に顕在化している。

つまり AI エージェントは「人が呼び出す」ものから「常駐して継続的にタスクを処理する」ものへと急速にシフトしている。

ただし、常駐型に切り替えた瞬間に運用面の難しさが一気に増す。社内導入や PoC を経て本番運用に進めようとしたチームが最初にぶつかる落とし穴は決まって 3 つだ。権限、監査、そしてコストである。

この記事ではそれぞれの落とし穴を具体的に整理し、さくらのクラウドを前提にした国産環境での実装指針まで踏み込んで書く。

落とし穴 1: 権限スコープが広がり続ける

常駐エージェントは「気が利く」ほど価値が出る。社内 Wiki も読める、Slack も投稿できる、CRM のレコードも更新できる、本番 DB のクエリも投げられる ── そう設計したくなる。

ところがこのアプローチは最小権限の原則と真っ向から衝突する。エージェントが暴走したときの被害範囲が、付与した権限すべてに広がるからだ。加えて、プロンプトインジェクションや内部関係者による誘導で意図しない操作が走るリスクは、エージェントの能力と比例して大きくなる。2026 年 4 月には Pillar Security が Google Antigravity のサンドボックス脱出脆弱性を公開し、5 月には Microsoft Semantic Kernel 経由でプロンプトから RCE に繋がる経路が報告された。抽象的なリスクではなくなっている。

そのため、実装側でやるべきことは大きく 2 つある。

ひとつはツール権限を役割ベースで束ねること。「営業ドメイン用エージェント」「経理ドメイン用エージェント」のように責務を切って、横断的な強権限を持つ単一エージェントを作らない設計が安全だ。

もうひとつは操作の可逆性で権限を分けること。読み取り系は広めに開放してもよいが、書き込み・削除・送信といった不可逆操作には人間の承認ステップを挟む。Anthropic の Claude Agent SDK や OpenAI の Responses API も、この「Human-in-the-loop」前提の設計を強く推している。

なお、さくらのクラウド上で動かす場合は 2026 年 2 月提供開始のIDポリシー機能が使える。エージェント用サービスプリンシパルに対して「実行可能な操作」と「操作対象リソース」を明示的に絞り込める仕組みだ。コントロールプレーン側で先に縛っておくのが、被害範囲を最小化するいちばん地味で効く一手になる。

落とし穴 2: 監査ログが「会話」になってしまう

では、監査ログはどう設計すべきか。従来の監査ログは「誰が・いつ・何のリソースに・どんな API を投げたか」を時系列で残せばよかった。AI エージェントを介すと、この構造が一気に崩れる。

エージェントの動作を後から追うには、最低でも以下をそろえて残す必要がある。

• ユーザーの指示プロンプト (原文)
• システムプロンプトと利用したコンテキスト (RAG で参照した文書 ID 含む)
• モデルが選んだツール呼び出しと引数
• ツールの実行結果
• 最終的にユーザーに返した応答

ここを残さないと、「なぜそのエージェントが本番 DB に DELETE を投げたのか」をインシデント後に追跡できない。つまり、プロンプトを残していないログは AI エージェントにおいては事実上の監査不能に近い。

実装面では、エージェントの実行フレームワーク (LangGraph、Mastra、Pydantic AI など) が出すトレースを構造化ログとして抜き出す。そのうえで、長期保管できるオブジェクトストレージに必ず流す設計が要る。コンプライアンス要件が厳しい組織であれば、改ざん検知付きストレージや WORM 設定も視野に入る。なお、さくらのクラウドは 2026 年に SOC2 Type1 を取得しており、監査証跡を国産環境に閉じたまま残せるという観点でも選択肢に入りやすくなった。

落とし穴 3: コストが「定額」ではなく「ふるまい次第」になる

さらに厄介なのがコストだ。常駐エージェントのコスト構造は、従来のサーバー型ワークロードとは性質が違う。CPU やメモリではなく入出力トークン量と推論回数で青天井に膨らむからだ。

特に怖いのは、エージェントが自分自身でツールを呼び続けてしまう「エージェント・ループ」だ。判断を誤ったエージェントが同じツール呼び出しを再帰的に繰り返し、半日でひと月分の API 予算を溶かすケースは実際に起きている。海外では再帰ループに入ったエージェントが 11 日間動き続け、$47,000 の API 課金を発生させた事例も報告されている。

ここで対策の柱は 3 つある。

1. 1 タスクあたりの最大ステップ数を必ず設定する。LangGraph では recursion_limit (デフォルトは 25) を環境に合わせて調整するか、自前ループに max_iterations を必ず持たせる。
2. モデルを段階分けする。判断は Haiku、複雑タスクのみ Sonnet/Opus、のようにルーターを噛ませることでコストは数倍単位で動く。
3. チーム別の予算アラートを出す。Anthropic Console の Workspaces 機能では、ワークスペース単位で月次の spend limit と通知メールを設定できる。閾値を超えたら自動停止できる仕組みを自前のダッシュボードと組み合わせて用意したい。

さくらのクラウドでの実装指針

ここからは国産環境、特にさくらのクラウドを前提にした具体的な構成パターンを書く。

2026 年 3 月 27 日、デジタル庁はさくらのクラウドをガバメントクラウドとして正式認定した。305 項目の技術要件をすべて満たした国産唯一のサービスで、AWS・Google Cloud・Azure・OCI と並ぶ 5 番目の選択肢になった。これは行政系・準公共系のワークロードを国産環境で動かす選択肢が一段現実的になったことを意味する。AI エージェントの導入においても、特にデータを国外に出したくない案件ではさくらのクラウドが第一候補に上がるケースが増えてきた。

ネットワーク設計: VPC とパケットフィルタで実行環境を隔離する

エージェントの実行ノードは、業務システムと同居させないのが鉄則だ。さくらのクラウドではスイッチ+ルーターで VPC 相当の独立セグメントを切り、外向き通信はパケットフィルタで LLM プロバイダーの IP レンジに絞り込む。社内システムへのアクセスは、VPN/専用線経由のホワイトリスト方式にする。マルチクラウド構成を取るなら、2026 年 4 月に GA となった AWS Interconnect (multicloud) のような専用接続サービスを使う選択肢もある。インターネット経由のトークン送信を避けられるからだ。

監査ログ: オブジェクトストレージへの長期保管

エージェントの構造化ログはオブジェクトストレージ (さくらのクラウド オブジェクトストレージ、もしくは S3 互換ストレージ) に流す。ログのキー設計を yyyy/mm/dd/agent_id/trace_id.json のような階層にしておくと、後からの監査検索が現実的なコストで回せる。

セキュリティ運用: CNAPP との連携

2026 年 4 月 27 日、さくらインターネットは国産クラウドセキュリティ「Cloudbase」と業務提携の基本合意書を締結した。常駐エージェントを動かすクラウド構成の設定ドリフトや、過剰な IAM 権限の検知は、CNAPP 系製品に任せると運用負荷が大きく下がる。Cloudbase は CSPM (設定ミス検知)・CIEM (過剰 IAM 権限検知)・IaC ドリフト検知をマルチクラウド統合で提供しており、エージェント用サービスプリンシパルが知らぬ間に権限を増やされる経路の継続監視に直接効く。国産クラウド × 国産 CNAPP の組み合わせは、データ主権を重視する案件で今後の標準解になりそうだ。

コスト管理: GPU ノードと従量課金の落とし穴

自前ホストの推論エンジンを使う場合、さくらの高火力シリーズを使うシーンが増える。ベアメタルの「高火力 PHY」、コンテナ実行の「高火力 DOK」、時間貸し VM の「高火力 VRT」と用途別に選べる構成だ。ただし、ここでも常時稼働ではなくスケジュール起動とアイドル停止を前提に組まないと、夜間や週末のコストがそのまま無駄になる。Slack 通知付きの予算アラートを最初から組み込んでおきたい。

セルフホスト型エージェントの選択肢: Hermes Agent

商用 API ではなく自前で常駐エージェントを立てるなら、Nous Research の Hermes Agent (MIT License) を高火力 VRT に載せる構成が現実的な選択肢に入る。バックエンド LLM は OpenRouter 経由で差し替えでき、データは自社環境に閉じる。Telegram・Slack・WhatsApp など複数のフロントを 1 プロセスで束ねられる点も常駐運用と相性がよい。

ただし、Hermes Agent の魅力でもある自動スキル生成には注意が要る。エージェントが実行ログから新しいスキルを Markdown として作って永続化していくため、生成スキルそのものが新しい権限経路になりうる。落とし穴 1 で触れた最小権限の原則を Hermes Agent でも貫くなら、生成スキルファイルのレビュー・承認フローを必ず挟む運用に倒すべきだ。

実装チェックリスト

導入前に最低限確認したい項目を 10 個に絞ると、こうなる。

1. エージェントの役割は責務単位で分割されているか
2. 不可逆操作には承認フローが入っているか
3. ツール権限は最小権限になっているか
4. プロンプト・ツール呼び出し・応答が構造化ログとして残っているか
5. ログは長期保管され、改ざん検知が必要か検討済みか
6. 最大ステップ数・最大トークン数のガードレールがあるか
7. モデル段階分けでコスト最適化されているか
8. チーム別予算アラートが設定されているか
9. 実行環境がネットワーク的に業務システムから隔離されているか
10. 設定ドリフトと過剰権限の自動検知が回っているか

よくある質問

Q. 常駐 AI エージェントを国産クラウドで動かすメリットは何ですか?
A. データを国外に出さずに済む点と、行政・準公共系で必須となるガバメントクラウド適合性が確保できる点です。さくらのクラウドは 2026 年 3 月に国産唯一でガバクラ認定を受けており、データ主権要件のある案件で第一候補になります。

Q. LangGraph の recursion_limit はどこまで下げるべきですか?
A. デフォルトは 25 です。タスクが平均 10 ステップ程度で完結する設計なら 30〜50 で十分。100 超を設定するなら、コスト上限と組み合わせて二重のガードレールを敷くべきです。

Q. Anthropic Workspaces の spend limit だけでコスト暴走は止められますか?
A. 月次の上限を超えると API アクセスが止まる仕組みですが、検知から停止までにラグがあります。アプリ側で max_iterations、トークン上限、Slack 通知を多層で組み合わせるべきです。

まとめ

常駐 AI エージェントは確実に来る潮流だが、運用設計を後回しにすると本番投入後に必ず痛い目を見る。権限・監査・コストの 3 軸で先に設計を固めることが第一歩だ。そのうえで、国産クラウド (特にさくらのクラウド) を選ぶ場合は VPC・オブジェクトストレージ・CNAPP・GPU 従量管理を組み合わせれば、実用的な常駐エージェント基盤は十分に組める。

PoC のあいだは「気が利く一体型エージェント」が魅力的に見えるが、本番では役割分割と監査の徹底こそが運用の差になる。

日々の業務で欠かせないのが、取引先やクライアントとのメール連絡。
ただ、件数が多いとその分時間も取られ、他の業務が圧迫されてしまうこともあります。

そこで今回は、今日からできる「社外メール（先方連絡）を効率化するコツ」をまとめました。

■ 件名で「内容＋目的」を明確にする

取引先とのメールは、件名のわかりやすさが信頼につながります。

• 【ご確認のお願い】見積書送付の件
• 【日程調整】来週の打ち合わせについて
• 【ご返信不要】資料共有のご連絡

件名を工夫するだけで、読み手の行動がスムーズになります。

■ 本文は「結論→詳細→補足」の順で書く

社外メールは、読み手に余計な負担をかけないことが重要です。
基本は以下の流れにするだけで、格段に読みやすくなります。

1. 結論：何をしてほしいか、何を伝えたいか
2. 詳細：背景や必要な情報
3. 補足：資料・ファイル・期限など

特に忙しい取引先には、「まず結論」がマナーとして喜ばれます。

■ よく使うフレーズはテンプレ化する

社外メールは毎回丁寧に書く必要がありますが、書く内容が大きく変わらない場面も多いです。
よく使う文はテンプレとして保存しておきましょう。

• いつもお世話になっております。株式会社〇〇の△△です。
• 以下、ご確認をお願いいたします。
• お手数をおかけしますが、よろしくお願いいたします。
• ご査収のほど、よろしくお願い申し上げます。

テンプレを使えば、ミス防止と時短につながります。

■ 返信期限を明確にする

「いつまでに返信すればいいのかわからない」と先方に負担をかけると、やり取りが長引きます。

• 〇日（〇曜）までにご返信いただけますと幸いです。
• 本日中にご確認をお願いいたします。
• 急ぎではございませんので、ご都合の良いタイミングでご連絡ください。

期限を明確にするだけで、やり取りのスピードが劇的に変わります。

■ 先方が返信しやすいように選択肢を提示する

日程調整や依頼内容は、相手が「すぐ回答できる」形にすると返信率が上がります。

• 【候補日】3/10（火）10:00〜 / 3/11（水）15:00〜 / 3/12（木）午前
• ご希望の形式をお知らせください（A案 / B案）

相手の手間を減らすことが、結果的に自分の時短になります。

■ AIに「文案の叩き台」を作らせる

社外メールは丁寧さと正確さが求められるため、AIの活用が特に効果的です。

• 文面の提案を作ってもらう
• 敬語の調整を任せる
• 言い回しを丁寧に整えてもらう

自分でゼロから作るより、AIに叩き台を作らせて調整する方が圧倒的に早く終わります。

■ まとめ：小さな工夫で先方とのやり取りがスムーズに

社外メールは「早く・正確に・わかりやすく」がポイントです。
件名の工夫、結論から書く、テンプレ化、期限明記、選択肢提示、AI活用。
この6つを実践するだけで、先方とのやり取りは確実にスムーズになります。

今日から取り入れて、メール対応の負担を大きく減らしていきましょう。

2026年4月24日、デジタル庁のガバメントAI源内（げんない）のソースコードがGitHubで公開された。リポジトリを開いてまず目に入るのは、CONTRIBUTING に書かれた一文だ。Pull Requestは受け付けていない。Issueも、データ損失やサービス障害、法令違反、重大なアクセシビリティ障壁に限定されている。

多くのOSSプロジェクトがPR歓迎の文言を掲げるなか、真逆の方針が堂々と書かれている。最初は違和感を覚えるが、読み進めるほどデジタル庁なりの筋が見えてくる。

そもそも源内とは何か

源内は、デジタル庁が内製で開発・運用している政府職員向けの生成AI利用環境だ。ガバメントクラウド上に構築されており、2025年5月にデジタル庁内部での提供が始まった。名前の由来は、Generative AI を縮めた GenAI の音読みと、エレキテルを復元した江戸時代の発明家・平賀源内を重ねたもので、役所の命名としてはかなり攻めている。

アーキテクチャは4層に分かれている。一番下がガバメントクラウドのコンピューティングリソース、その上がAIエンジン層で、ここで複数のLLMを切り替えながら実行できる。さらにAPI層が既存の府省庁システムと繋がり、最上位には行政実務に特化した20種類以上のAIアプリケーションが並ぶ。

アプリ層の顔ぶれが興味深い。汎用のチャット、要約、校正に加えて、法制度調査を支援する Lawsy、国会答弁検索、公用文チェッカーといった業務特化型が揃う。法律条文を横断検索して回答するようなAIは、民間のチャットボットラッパーでは手が出しにくい領域になる。

ここで見逃せないのが、源内そのものがさらに上流のOSSを土台にしている事実だ。ベースになっているのは、AWS Japan のボランティアが中心になって開発している Generative AI Use Cases、略して GenU。民間OSSを政府が拡張して庁内で運用し、その拡張分をふたたびOSSとして戻している。往復構造ができあがっているわけだ。

利用実績レポートから見える現場の姿

ここからが面白い。デジタル庁は2025年8月、職員による源内の利用実績を公開しており、数字を追うとかなり具体的な状況が見えてくる。

3ヶ月間の集計で、対象約1,200人のうち950人が利用。利用率にして約80%にのぼる。総利用回数は65,032回、1人あたり平均70回。週ごとの利用回数は3,000〜6,000回のレンジで推移している。業務効率化を実感したかというアンケートでは、110人中79.1%が肯定的に回答した。

具体的な時短事例も公開されている。Teams会議の議事録作成で10分程度、VBAマクロの自動生成で数時間、マニュアル検索で30分〜1時間の短縮。役所仕事の地層を成しているのが議事録と表計算で、そこが素直に省力化できている事実は、そこそこ効いている。

一方で、同じレポートのなかで目を引くのは、使われ方の偏りのほうだ。ヘビーユーザー150人以上が3ヶ月で100回以上使っているのに対して、170人は5回未満にとどまる。さらに踏み込むと、係員級の半数以上が50回以上使っている一方で、課長級の半数は利用実績ゼロ、という段差が出ている。民間から出向してきた専門人材は最高利用率を示した。

これは源内の性能の話ではなく、組織とリテラシーの話だ。末端で使うほどメリットの大きい道具を、権限を握っている層が触っていない。下から有効性を訴えても、上にピンと来ていなければ、申請フローや許容される使い道は広がらない。OSS公開というニュースの裏には、この上の層にどう触らせるかという、技術では解けない宿題が残っている。

Lawsy開発チームの内幕

源内を語るうえで、法制度調査AI Lawsy（ロージー）は外せない。もとはデジタル庁主催の法令×デジタルハッカソンから生まれたプロトタイプで、その後、源内の行政実務特化アプリのひとつとして磨き上げられていった。

開発チームは PolicyGarage の note に詳細な記録を残している。コアメンバーは3名。国家公務員でデータ分析とAIを担当する鈴木宏和氏、DSPy実装を中心に技術面を支えた白川達也氏、フロントエンドの神代洋明氏。この小さなチームが、本番LLMに OpenAI GPT-4o、フレームワークにスタンフォード大学発のリサーチツール STORM が採用する DSPy、フロントエンドに Streamlit を選んで作り上げた。

興味深いのが、途中でターゲットペルソナを変更した経緯だ。当初は専門家レベルの法令調査を助けるツールを目指していたが、ハッカソン期間内では精度が間に合わず、法令に詳しくない人向けの解説ツールへと舵を切り直している。この手の方向転換は民間のプロダクト開発では日常茶飯事だが、官公庁発のプロジェクトで公然と記録に残っていることのほうが珍しい。

技術の苦労も具体的だ。e-gov の法令データはXMLで提供されているが、チャンク化しようとすると文脈の維持と処理効率のトレードオフにぶつかる。Web検索APIの文字数上限、具体的には Tavily の400字制限に長いクエリが引っかかり、クエリ自動最適化のワークフローを挟むことになった。STORM の6段階パイプラインを Lawsy 独自の9段階に再編したのも、法令特化ゆえの要請だった。

こういう手触りの話が一次情報として残っているのは貴重で、源内を巨大な箱ものとして語るイメージを壊してくれる。実際には、顔の見える小さなチームが、民間のハッカソンと変わらない試行錯誤を重ねた成果物に、政府の名前が冠されている。

公開されたリポジトリの中身

公開されているリポジトリは大きく2つ。Web側の digital-go-jp/genai-web と、アプリ側の digital-go-jp/genai-ai-api だ。

Web側 — digital-go-jp/genai-web

ユーザーインターフェースを担うのがこちら。言語構成は TypeScript 99%、主要ライブラリは React と Tailwind CSS、インフラは AWS CDK。冒頭で触れたとおり、AWS の GenU をベースに、デジタル庁が機能を追加した格好になっている。拡張内容は次のあたりが中心になる。

• チーム管理機能
• AIアプリ管理機能。外部マイクロサービスとして生成AIアプリを追加し、実行できる
• デジタル庁デザインシステムの適用
• 庁内アクセシビリティチームによる試験の反映
• 運用監視とモニタリング機能

GenU がAIアプリの一般的なひな型だとすれば、源内Webは大規模組織での運用に耐える業務基盤まで踏み込んだ拡張になっている。この差分を読むだけでも、組織内AIプラットフォームを構築したい人にとっては教材として値打ちがある。

ライセンスは MIT が中心だが、一部の Lambda や CDK ファイルは Amazon Software License の対象になる。フォークして再配布するなら、ファイル単位のヘッダ確認が必要だ。

アプリ側 — digital-go-jp/genai-ai-api

行政実務向けAIアプリの実装が置かれているリポジトリ。言語比率は Python 44%、Bicep 25%、TypeScript 25%。Web側とはまったく異なるスタックで、ここにマルチクラウド前提の設計思想がはっきり表れている。

収録されているテンプレートは3つある。

• AWS には行政実務用RAGの開発テンプレート
• Azure にはLLMをセルフデプロイして利用する開発テンプレート。IaCは Bicep
• Google Cloud には最新の法律条文を参照して回答する法制度AIアプリの実装

AWS、Azure、Google Cloud それぞれにサンプル実装が整理されているのは、率直にいって気合が入っている。自治体や企業の側では、手持ちのクラウド契約や調達制約によって採用候補が変わる。そこを政府が特定のクラウドに寄せろと押し付けないよう、意図的にフラットな構えで作られている。

特徴的なOSSポリシー

冒頭で触れた、PRを受け付けず Issue は致命的案件のみという方針は、従来型のOSSコミュニティの感覚からすると違和感を覚えるものだ。一緒に作ろうではなく、参照してくださいに近い。

ただ、政府OSSとしては筋が通っている。Pull Request を受け入れるということは、受け取った側が法的責任と運用責任を負うことを意味する。政府基幹システムに組み込まれるコードに、誰が書いたか分からない変更を取り込むのは、たしかに難しい。公開はするが統治は中央で、という姿勢を明示してくれるほうが、使う側としても判断しやすい。

国産LLM 7モデル選定という布石

源内のOSS公開と並行して、もうひとつ動いているのが国産LLMの選定プロセスだ。2026年3月、デジタル庁は15件の応募から7モデルを選定したと発表した。内訳は次のとおりで、名前を並べるだけで日本のLLMプレイヤーの現在地が見えてくる。

• tsuzumi 2（NTTデータ）
• CC Gov-LLM（カスタマークラウド）
• Llama-3.1-ELYZA-JP-70B（KDDI・ELYZA共同応募体）
• Sarashina2 mini（ソフトバンク）
• cotomi v3（日本電気）
• Takane 32B（富士通）
• PLaMo 2.0 Prime（Preferred Networks）

選定基準は、国内で開発された大規模言語モデルで、開発経緯や開発方法が具体的に説明可能であること、そして行政実務で使える性能を持ち、デジタル庁のテストを通過していることだった。2026年度は無償で試用、2026年8月ごろから源内で順次稼働し、2027年4月以降の政府調達を視野に入れている。

この動きとOSS公開は無関係ではない。基盤はオープンにし、モデルは国産重視でという二段構えで、ガバメントAI全体の独立性を確保しにいっている。先行して導入された Preferred Networks の PLaMo Translation はすでに政府職員向けの提供が始まっており、翻訳という比較的評価しやすいタスクから実地データを集める段階に入っている。

海外の政府AIとの温度差

比較軸として、海外の政府AI事情に目を向けておきたい。国ごとに思想がかなり違っていて面白い。

シンガポールのPairは、政府職員向けチャットボットの先行事例だ。GovTech が開発し、トライアル開始から2ヶ月で100以上の政府機関、1万1,000人以上が利用したという。建設庁ではレポートレビューの時間を数時間から数分に短縮したと報告されている。源内の80%利用に近い浸透度で、日本とシンガポールはここでは似た立ち位置にいる。

エストニアのBürokrattは方向性がかなり違う。政府チャットボットでありながら、民間企業が自社サービスを統合できる仕組みを持っており、天候情報などは外部から提供されている。2026年以降は個別職員向けのAIエージェント化と、他国政府との相互接続まで視野に入れている。行政の内側にとどまらず、国境を越えたエコシステムとして設計されている点で、源内とは発想が違う。

日本の源内はシンガポール型の職員向け内製基盤を起点にしつつ、エストニア型のエコシステム志向を、今回のOSS公開で手前から試みているようにも読める。コードを開くことで、民間SIerや自治体が組み込みやすい状態を作り、少しずつエコシステム寄りに寄せていく狙いが見える。

民間SIerにとっての変化

この動きは、行政向けシステム開発を主業にしてきたSIerにとっては無視できない。自治体向けに独自の生成AI基盤を売る余地はこれまで十分にあったが、源内互換を語れるかどうかで、提案の意味が変わってくる。

現実的な構図は次のように整理できる。

• フルスクラッチ型の提案は、差別化できる独自性がない限り厳しくなる。自治体側は、源内を参考にしてこの金額なのかと問える立場になる。
• 源内の運用とカスタマイズ支援は新しい商売になりうる。そのまま動かすには手直しがいる以上、そこを埋めるコンサルや運用委託の需要は出てくる。
• アプリ層での差別化は十分可能だ。法令、税務、福祉、教育といった業務特化のAIアプリは、政府の汎用基盤だけではカバーしきれない。

自治体のDX担当者からすれば、源内のこの機能は標準で入っていますが御社の提案には含まれていますか、というフラットな問いを投げられるようになったこと自体が大きい。ブラックボックスのなかで見積もりを受け取る時代から、少しずつ抜け始めている。

触る前に押さえておきたい注意点

現実的な落とし穴もいくつかある。

• 公開されているのはアプリと基盤のコードで、LLM本体は含まれていない。動かすには Azure OpenAI や Amazon Bedrock、あるいは国産LLMを別途用意する必要がある。
• 政府向けの脅威モデルと民間のそれは同じではない。コードを流用しても政府水準のセキュリティが自動的に引き継がれるわけではない。認証や監査ログ、秘匿情報の扱いは自組織の要件で設計し直すことになる。
• ライセンスの混在もある。MITが中心だが、一部のファイルは Amazon Software License なので、再配布時はファイル単位で確認を。
• コミュニティとの付き合い方にも注意がいる。PRが受け付けられない以上、独自拡張は基本的にフォーク側で管理することになる。本家への追随にはそれなりのコストが乗る。

独自の視点 — 参照実装としての政府OSS

今回の公開は、典型的なコミュニティ型OSSとも違えば、単なる成果物の公表とも違う、その中間に位置している。PRを受け付けない政府OSSは、参照実装、いわゆる reference implementation に近い姿をしている。自由に使っていいが、正典はあくまで中央にある。

この形が日本の行政に馴染む理由は、おそらくふたつある。ひとつは、法的責任のラインをぼかさずに済むこと。もうひとつは、自治体や企業が本家に合わせて作り直さなければいけないというプレッシャーから解放されることだ。源内のコードをそのまま使わなくていい。自組織の事情に合わせて切り貼りすればいい。本家は本家で独立して進む。

このやり方が上手くハマれば、今後ほかの政府OSSも似たポリシーで出てくる可能性は十分ある。法令APIやベース・レジストリの周辺、マイナポータル系のツールチェーン、自治体共通DBの周辺など、公開可能な素性を持つアセットはまだ残っている。源内のOSS公開は、日本的な政府OSSの型を作りにいった一手として捉えた方が、ニュース単体で見るより視野は広がる。

もうひとつ書いておきたい違和感がある。利用実績レポートの、課長級の半数が利用ゼロという数字は、OSS公開では動かない指標だ。コードを開いても、管理職がAIを触るようになるわけではない。ここは教育や人事評価、権限設計の領域で、技術OSSの射程外になる。源内というソフトウェアが、使える人のところにだけ届き、使えない人のところには届かないというリスクは、自治体に展開しても同じ形で再現されるはずだ。技術の話と組織の話を切り分けずに語ると、源内を入れたのに変わらないという結論に早晩ぶつかる。

最後に

公共機関のAIプロジェクトは、これまで外から中身の見えない箱だった。仕様書や調達資料は読めても、実際にどう動いているコードなのかは関係者以外には分からなかった。

源内のOSS公開は、そこに小さくない穴を開けた。自治体は重複開発から降りる選択肢を手にし、開発者は行政ドメインのRAGやマルチテナント設計を教材として手に取れる。民間SIerは源内互換という新しい会話のレイヤーを持ち、発注側はブラックボックスのなかで見積もりを受け取る状況から一歩抜けられる。

EastCloudでも、自治体や中堅企業向けの業務システム開発と生成AIの社内実装に日常的に取り組んでいる。源内のリポジトリは、日本の行政ドメインでRAGやマルチテナントをどう設計するかを考える上で、当面は重要な参照点になりそうだ。手元で動かしてみるなら、まず digital-go-jp/genai-web をクローンして docs/ を読むところから始め、次に genai-ai-api 側の AWS、Azure、Google Cloud テンプレートを目的に合わせて触ってみるのが現実的だろう。

ただし、OSSの公開だけで片付く話ではない。課長級の利用ゼロ問題、セキュリティ要件の再設計、運用人材の不足。ソフトウェアが手に入っても、組織が使いこなせるようになるかは別の話だ。そこが埋まって初めて、源内は政府が作った便利なコードから、日本の行政DXのインフラに昇格する。

国が作ったAI基盤を、個人や地方自治体が自分たちの土俵に引き込める段階に入った。使いこなせるかどうかは、ここからの動き方にかかってくる。

参考リンク

• ガバメントAI「源内」をOSS（オープンソースソフトウェア）として公開しました｜デジタル庁
• ガバメントAI「源内」をオープンソースとして公開します｜デジタル庁公式note
• digital-go-jp/genai-web — GitHub
• digital-go-jp/genai-ai-api — GitHub
• Generative AI Use Cases (GenU) — AWS Samples
• Government AI “GENAI”｜Digital Agency（英語ポリシーページ）
• 【解説】ガバメントAIとは？デジタル庁が進める政府AI活用戦略【源内】
• 行政の未来を切り拓く。デジタル庁「AI班」の奮闘に密着｜デジタル庁ニュース
• 行政と技術の融合を目指して — 法令Deep ResearchツールLawsyの開発記録｜PolicyGarage
• デジタル庁「源内」で判明！政府AI活用の衝撃格差と8割が実感した効果
• デジタル庁「デジタル庁職員による生成AIの利用実績」レポート解説
• デジタル庁、ガバメントAI用国産LLMを選定 tsuzumi 2やPLaMo 2.0など — Impress Watch
• デジタル庁、政府AI基盤「源内」で国産LLMを試用へ 7モデルを選定 — Ledge.ai
• 政府AI「源内」オープンソース化 GitHubで公開、商用利用もOK 民間と共創へ — ITmedia
• デジタル庁、政府AI「源内」をオープンソースとして無料公開 — ASCII
• デジタル庁、ガバメントAI「源内」をオープンソース公開 — Impress Watch
• Estonia eyes cross-border interoperability for Bürokratt, its ‘Siri of public services’ — GovInsider
• 公務用チャットボットから脱税摘発まで｜生成AI海外事例集 ー 公共セクター編