2026年5月、マネーフォワードのGitHub認証情報が漏れ、リポジトリが丸ごとコピーされた。
本番データベースは無事だったのに、銀行連携は全面停止し、復旧は長引いた。
壁の内側は守れていたのに、壁の外の一点が抜かれただけで、サービスは止まった。
この事案を掘っていくと、妙なことに気づく。
SaaSへの依存、AIエージェントの権限、クラウドベンダーの選定。
レイヤーを変えても、同じ形の問いが何度も戻ってくる。
「信頼を、どこに置くか」。
そして、その問いへの答えは、毎回同じ方向を指している。
マネーフォワード事案とSaaSの構造的リスク
何が起きたか
まず、何が起きたのかを押さえる。
2026年5月1日、マネーフォワードのGitHub認証情報が漏えいし、第三者がリポジトリを丸ごとコピーした。
流出の可能性があるのは、ビジネスカード370件のカード保持者名（アルファベット）とカード番号の下4桁だ。
本番データベース（口座情報や家計情報）からの漏えいは確認されていない。
それでも、銀行口座連携は全面停止となり、5月9日時点でも多くの金融サービスで再開の見通しが立たなかった。
通常、ソースコードに個人情報は含まれないはずだ。
だが、サービス更新作業の過程で、個人情報を含むファイルが管理手順を外れてGitHub上に置かれていた。
つまりこれは、技術的な脆弱性というより、運用とガバナンスの問題だ。
復旧が長引いたのにも、理由がある。
コード内の認証キーやパスワードの無効化と再発行は、ほぼ完了していた。
それでも、各提携金融機関との安全性確認が、一社ずつ個別に必要だった。
GW連休と重なって協議が進まず、銀行法に基づく電子決済等代行業者としての慎重さもあった。
SaaSが構造的に抱えるリスク
この一件は、特定企業の不注意で終わる話ではない。
SaaS全般に通じる、構造的なリスクを照らし出している。
- 攻撃面の拡大。サービス本体のDBを守っても、開発基盤（GitHub）、CI/CD、依存ライブラリ、社員の認証情報管理と、攻撃面は広く散らばる
- 連鎖リスク。多数の外部サービスとAPI連携することがSaaSの価値だが、それが一社のインシデントの影響を増幅させる。銀行連携停止の長期化が、まさにこれだ
- 業界共通の弱点。同時期にCAMPFIREもGitHub経由で不正アクセスを受けた。特定企業ではなく、「GitHub認証情報の管理」という業界横断の弱点が露呈した
ゼロトラストとAIエージェント時代の権限設計
既存の仕組みを「ちゃんとやる」こと
では、どう守るのか。
侵入される前提で被害を局所化する、という方向へ進めると、意外な結論に着く。
ゼロトラストは、特別な新技術ではない。
既存の仕組みを、徹底することに帰着する。
- IAMロールで、アクションとリソースを最小限に絞る
- シークレットをコードに埋めない（Secrets Manager等で分離する）
- トークンの有効期限を短くする
- ネットワークをセグメントで分ける
多くの組織がこれを「ちゃんとやれていなかった」のは、技術力の問題ではない。
境界防御、つまり「侵入されない前提」の思考が根にあったからだ。
壁の内側は信頼できる、と思っているかぎり、内側の権限設計は甘くなる。
具体的な権限の絞り方
最小権限といっても、抽象論では動けない。
S3を例にとると、具体的なパターンがいくつもある。
- 一方通行の設計。ログ収集ならPutObjectだけ許可し、GetObject/DeleteObjectは不許可にする。バージョニングを有効化して上書きされても復元でき、かつエージェント自身にバージョニング無効化の権限を与えない
- リソースレベルの絞り。ARNでプレフィックスを限定し、エージェントごとに触れる領域を分ける
- 条件キーによる動的制約。SourceIpやPrincipalTagで、特定のVPCやタグ付きロールからのみ許可する
- 時間軸の制約。STSの一時クレデンシャルを最小期限で発行し、使い捨ての鍵として運用する
- deny優先の設計。SCPやPermissions Boundaryで「絶対にやらせない操作」の天井を先に決め、allowの設定ミスがあっても致命的操作に届かせない
AIエージェントが入ると重要度が上がる
この最小権限は、AIエージェントが入ると、重要度が一段上がる。
人間は、自分の操作を意識できる。
だがエージェントは、与えられた権限の範囲で自律的に動く。
過剰な権限は、そのまま意図しない操作の連鎖に化ける。
しかも、エージェントが使うクレデンシャルは長時間有効になりがちで、攻撃者の格好の標的になる。
だから、静的な絞り（IAMポリシー）だけでは足りない。
セッション単位の一時クレデンシャル、人間の承認を挟む仕組み、異常検知による自動失効。
動的な制御が、ここで効いてくる。
SaaS依存からの回帰と信頼のピラミッド
SaaSの信頼性をどう見るか
ここで、もっと手前の問いが戻ってくる。
そもそも、SaaSをどこまで信頼するのか。
マネーフォワードのような上場企業でも、インシデントは起きる。
中小規模のベンダーになれば、セキュリティ水準はさらに見えにくい。
SaaSを一つ導入するたびに攻撃面が広がり、そのベンダーのリスクを背負い続けることになる。
コーディングエージェントによる自前構築の現実味
これまでSaaSを使ってきたのは、自前で作るコストが見合わなかったからだ。
だが、その前提が揺れている。
AIエージェントによって構築コストが劇的に下がれば、SaaSを介さずAWS上に自前で組む、という選択肢が現実味を帯びる。
外部にデータを預けないぶん、攻撃面は確実に減る。
ただし、代償もある。
自前構築なら、継続的な保守（脆弱性パッチ、ライブラリ更新、ベストプラクティスへの追従）は自己責任だ。
判断の軸は、「そのSaaSにどれだけ機微なデータを預けるか」に尽きる。
金融情報を預けるサービスと、タスク管理ツールとでは、リスクの重みがまるで違う。
信頼を突き詰めると大手クラウドに収束する
信頼を突き詰めていくと、行き先は一つに収束する。
AWSやGCPのような、大手クラウドベンダーだ。
セキュリティそのものがビジネスの根幹で、投資規模も動機も桁が違う。
中間のSaaS層を薄くして、マネージドサービスで直接組むほうが、攻撃面は減る。
だが、ここで止まらないのが、この思想の徹底ぶりだ。
AWSも、絶対ではない。
データが標準フォーマットで持ち出せて、別基盤に移せる設計が、保険になる。
Terraformやコンテナで、クラウドベンダーをまたぐ抽象化を噛ませておく。
完全な信頼をどこにも置かないという姿勢は、ベンダー選定の層にまで及ぶ。
冒頭の「同じ方向」が、ここで見える。
境界防御からゼロトラストへ。
SaaS依存から依存先の最小化へ。
人間の操作の信頼から、エージェントへの権限制約へ。
特定クラウドの信頼から、ポータビリティの確保へ。
レイヤーは違っても、答えはすべて「信頼を前提にしない」を指している。
これは技術の設計パターンであると同時に、不確実性に対する思考の型でもある。
どこに信頼を置くかを問い続けるかぎり、この型は次のレイヤーでも、また同じ顔で戻ってくる。