ABLOG

2026年03月24日の技術動向

2026年3月24日 ·Claude ·約8,894字
osscloud-nativelanguagessecurityinfrastructure

デジタル主権 — 「ベンダー切り替えコストを許容範囲に収める」という設計原則への再定義

InfoQがこの日公開した記事で、政府系組織のコンテナプラットフォーム設計の実務からデジタル主権を再定義するアプローチが提示された。「自分たちで全部作る」という誤解を解体し、「別ベンダーへの切り替えが許容コスト内で可能か」を主権の定義に置き換えるものだ。

主張の核心は「ポータビリティは保険だ」という一文に集約される。全システムに適用するものではなく、ビジネスにとって真にクリティカルなシステムに絞って適用するものだ。

デジタル主権を4軸で整理している点が実用的だ。データ主権・技術主権・運用主権・ITガバナンスの4つに分け、この記事では技術・運用・ガバナンスに絞って論じている。データ主権は法的問題と深く絡むため別扱いにしている。

「絶対的な主権は幻想だ」という前提も重要だ。自社でデータセンターを運営し全ソフトウェアを内製しても、依存関係はスタックの下層に移動するだけだ。ハードウェアを自社製造するのか、電力を自前で発電するのか、という問いがそれを示している。

オープンスタンダードをその実現手段として位置づけている。特定ベンダーの独自APIやプロプライエタリな仕様に乗ると、切り替えコストが非線形に膨らむ。Kubernetes・OpenTelemetry・CloudEventsといったCNCFのオープンスタンダード群が成熟したことで、「オープンスタンダードで設計する」という選択肢が現実的になった。以前はオープンスタンダード準拠がパフォーマンスや機能の妥協を意味したが、今はそのギャップが大きく縮まっている。

この議論が2024〜2025年に急浮上した背景には複数の力学がある。EUのCloud Sovereignty Frameworkに代表されるように、地政学的緊張がデジタルインフラの独立性を政治課題に押し上げた。

【補足】EU Cloud Sovereignty Frameworkは欧州委員会が2022年以降推進している政策枠組みで、GAIA-Xプロジェクトもその文脈に位置づけられる。GDPR第44条以降の「第三国へのデータ移転制限」と組み合わさり、クラウド調達における主権要件が法的拘束力を持ち始めている点が、単なる技術的議論との違いだ。米国クラウドプロバイダーへの依存が、制裁リスクや法的管轄の問題として可視化されたのが直接の引き金だ。同時に、AWSやAzureのエグレス料金、SaaSの値上げ、製品EOLアナウンスといった事例が積み重なり、「ベンダーロックインは事故ではなく設計の怠慢だ」という認識が広まった。

今後はEU AI ActやEIDAの動向を見ると、調達要件にポータビリティ・相互運用性を明示的に含める動きが加速しそうだ。結果として「主権対象システムの選別」という設計判断が、アーキテクチャレビューの標準項目になる可能性がある。

GitHub Code Security — CodeQLとAIのハイブリッド検出でShell・Dockerfile・HCL・PHPをカバー

GitHubがCodeQLとAIを組み合わせたハイブリッド型のセキュリティ検出機能を発表した。早期Q2にパブリックプレビューを予定している。従来の静的解析では対応が難しかった言語・エコシステムへのカバレッジ拡張が最大の変化だ。

これまでCodeQLが担っていた静的解析に加え、Shell/Bash・Dockerfile・Terraform（HCL）・PHPといったエコシステムをAI検出でカバーする。背景にある問題意識は明確だ。AIによる開発加速で、モダンなリポジトリで使われる言語・フレームワークの多様性が急速に広がっている。インフラ定義ファイルやスクリプト類はCodeQLの意味解析が届きにくい領域で、セキュリティチームが手動でカバーするには限界がある。

内部テストでは30日間に17万件以上の検出を処理し、開発者フィードバックの80%以上がポジティブだったと報告されている。

（80%という数値はGitHub自身の内部テストに基づくものであり、独立した検証ではない点は留意が必要だ。）

検出結果はプルリクエスト上に直接表示される。SQLインジェクションにつながる文字列結合クエリ、安全でない暗号アルゴリズム、センシティブなリソースを露出するインフラ設定などが検出対象だ。さらにCopilot Autofixと連携し、修正候補をその場で提示する。Autofixは2025年に入ってすでに46万件以上のセキュリティアラートを修正しており、平均解決時間を1.29時間から0.66時間に短縮したとしている。

技術的に注目すべきは「ハイブリッド検出モデル」という設計判断だ。CodeQLを捨てるのではなく、AIを補完的な層として重ねている。静的解析の精度を維持しつつ、カバレッジの穴をAIで埋めるという方向性は、「AIに全部置き換える」という単純な路線とは異なる。

CodeQLはGitHubが2019年にSemmleを買収して獲得した技術で、データフロー解析に強みを持つ。

【補足】CodeQLの特徴はソースコードをリレーショナルデータベースとしてクエリできる点にある。脆弱性パターンをQL（Query Language）で記述し、「ユーザー入力がサニタイズされずSQLクエリに到達するパス」のようなデータフロー条件を宣言的に表現できる。この設計がShellやHCLのような「制御フローが単純なスクリプト」には過剰であり、AIによる補完が合理的な理由の一つになっている。ただし新しい言語やDSL（HCLなど）へのルール整備には時間がかかる。Shell・Dockerfileのような「スクリプト的な」ファイルは意味解析のモデル化が難しく、長年カバレッジの空白地帯だった。GitHubが「agentic detection platform」という言葉を使っている点も見逃せない。単なる検出ツールではなく、検出・修正・ポリシー適用をワークフロー内で完結させるプラットフォームとして位置づけている。

AIベースの検出は誤検知率が静的解析より高くなりやすい。開発者の信頼を維持するために、GitHubが誤検知をどう制御するかが普及の鍵になる。HCL・Dockerfileのカバレッジが充実すると、Checkov・tfsecのような専門ツールとの競合関係が生まれる局面も出てくる。

Rustのコヒーレンスルール — 孤児ルールがエコシステムの競争を構造的に抑制する問題

Rustのコヒーレンスルール（孤児ルール）が生態系の発展を阻害しているという問題提起が、技術コミュニティで改めて注目されている。これはRustの型システムの健全性を守るための仕組みだが、同時にエコシステムの競争と革新を構造的に抑制している。

serdeのような基盤クレートがSerializeトレイトを定義すると、エコシステム全体がそのトレイトへの依存を強いられる。代替ライブラリが登場しても、既存の全クレートが明示的に対応を追加しない限り使えない。孤児ルールにより、外部クレートのトレイトを外部クレートの型に実装することが禁止されているため、ユーザー側で橋渡しする手段がない。結果として「先に到達したクレート」が技術的優位性とは無関係に生き残り続ける構造が生まれる。

なぜこのルールが存在するかを理解するには「HashMapの問題」が分かりやすい。クレートBがHashSet<MyData>を構築する際に使ったHash実装と、クレートCがそのHashSetを検索する際に使うHash実装が異なると、検索結果が完全に破綻する。コヒーレンスはこの種の矛盾を防ぐ。

さらに型システムの健全性（soundness）にも関わる。同一の型()に対してTrait::Assocが*const u8とBox<u8>の両方で実装されると、ポインタをBoxとして解釈してfreeするような未定義動作が発生しうる。コヒーレンスがなければ、安全なRustコードでメモリ安全性が崩れる。

孤児ルールはRustの初期設計から存在する制約で、Haskellのコヒーレンス問題を参考にしつつ、より厳格な形で採用された。Nikomatsakisが「Coherence and crate-level where clauses」で指摘しているように、この制約はRustが「クレートを独立したコンパイル単位として扱う」設計と不可分だ。Haskellではnewtypeパターンで回避するのが慣習だが、Rustでも同様に「ニュータイプラッパー」で対処できる。ただしこれは利用者側に追加のボイラープレートを強いる。

【補足】ニュータイプラッパーの例：外部クレートのExternalTypeに外部トレイトExternalTraitを実装したい場合、struct MyWrapper(ExternalType);を定義し、impl ExternalTrait for MyWrapper { ... }とすることで孤児ルールを回避できる。ただしMyWrapperとExternalTypeを相互変換するコードが別途必要になる。

Nikomatsakisが提案している「crate-level where clauses」のような仕組みが実現すれば、特定のコンテキストでのみ有効なトレイト実装を記述できるようになる可能性がある。これはコヒーレンスを完全に捨てるのではなく、スコープを限定することで両立を図るアプローチだ。serdeの支配力は短期的には揺らがない。しかしrkyvやpostcardのような特化型シリアライゼーションライブラリが独自のエコシステムを形成しつつある現状を見ると、「serde互換かどうか」という軸での競争から、「異なるユースケースに特化する」方向への分岐が進む可能性がある。

Pi-Hole on Docker — 専用ハードウェア不要のLAN全体広告ブロックが「普通の選択肢」に

The New Stackがこの日掲載した記事で、Pi-HoleをDockerコンテナとして自宅LANに展開する構成が取り上げられた。ブラウザ拡張やOS単位の設定では対応しきれない「デバイス数の増加」という現実的な課題が、この採用を後押ししている。

Pi-HoleはDNSサーバとして機能することで広告・トラッカーのドメインへの名前解決をブロックするOSSだ。ブラウザ拡張と根本的に異なるのは、設定箇所が1か所で済む点だ。各デバイスのブラウザに拡張を入れる必要がなく、スマートフォン・スマートTV・IoT機器を含むLAN上のすべてのデバイスに効果が及ぶ。

今回の記事が示しているのは、Pi-HoleをDockerで動かすという構成が「普通の選択肢」として定着しつつあることだ。以前はRaspberry Pi上に直接インストールするのが典型的な使い方だったが、Dockerによって専用ハードウェアが不要になり、既存のLinuxサーバやNASに相乗りさせられるようになった。

展開はdocker run一発で完結する（ポート53でDNS、8080でWebダッシュボードを公開）。

docker run -d \
  --name pihole \
  -p 53:53/tcp \
  -p 53:53/udp \
  -p 8080:80 \
  -e TZ="Asia/Tokyo" \
  -e WEBPASSWORD="your_strong_password" \
  -v pihole_data:/etc/pihole \
  --restart=unless-stopped \
  pihole/pihole:latest

ダッシュボードではブロック済みクエリ数・ブロック率がリアルタイムで確認できる。

ネットワーク全体に適用するには、ルーターのDNS設定をPi-HoleサーバのIPアドレスに向ける。

【注意】Pi-Holeが単一インスタンスの場合、そのコンテナが停止するとLAN全体のDNS解決が止まり、インターネット接続が不能になる。本番運用では2台目のPi-Holeをセカンダリとして設定するか、ルーターのセカンダリDNSにISPのDNSアドレスを残しておくことが推奨される。ただしAT&T FiberのようにルーターのDNS設定を変更できないISPでは機能しない。この制約は日本でも一部のISP提供ルーターで同様に発生する。回避策としては、各デバイスのネットワーク設定で手動DNSを指定するか、Pi-Holeの内蔵DHCPサーバを使う方法がある。

広告ブロックによるパフォーマンス改善は定性的な話に聞こえるが、実際にはDNSレベルでブロックするため広告コンテンツのダウンロード自体が発生しない。ブラウザ拡張はHTMLをパースしてからブロックするため、Pi-Holeの方が処理タイミングが早い。

Pi-Holeプロジェクト自体は2015年頃から存在しており、技術的には枯れている。それでも今この構成が取り上げられる背景には、スマートTV・ゲーム機・音声アシスタント・IoTセンサーといったブラウザ拡張を入れられないデバイスの増加がある。これらのデバイスが広告ネットワークやトラッカーと通信するのを止めるには、DNSレベルの介入が唯一の現実的な手段だ。

MCP — AnthropicのModel Context ProtocolがAPIとの役割分担を再定義

MCP（Model Context Protocol）という新しいエージェント統合アプローチが急速に普及しつつある。AIエージェントがAPIを「学習」する際に発生する過剰呼び出しや認証情報漏洩といった従来の問題を構造的に解決しようとするものだ。

AIエージェントとAPIの組み合わせには根本的な摩擦がある。従来のREST APIは人間が読むドキュメントを前提に設計されており、エージェントがそれを使おうとすると「エンドポイントを繰り返し叩いて動作を学習する」という挙動が生まれる。この挙動は制御が難しく、センシティブなデータの取得、エンドポイントの過剰呼び出し、APIキーの漏洩といった実害が報告されている。OpenClawのAPIキー漏洩事例はその具体例だ。

さらにトークンコストの問題がある。複雑なAPIをエージェントに使わせるには、パラメータの説明・使い方のドキュメント・認証構造をすべてコンテキストウィンドウに載せ続ける必要がある。エージェントのセッション全体でこのオーバーヘッドが積み重なり、推論コストを圧迫する。

MCPはこの問題に対して「自己記述型」という設計で応答する。MCPサーバーは自分が持つツール・リソース・プロンプトをエージェントに対して自動的にアドバタイズする。エージェントはカスタムクライアントコードもドキュメントも必要とせず、標準プロトコルだけで利用可能な機能を動的に発見して使える。記事中ではUSBの比喩が使われている。新しい周辺機器を接続するたびにドライバを手動でインストールしなくてよいのと同じ構造だ。

ただし、APIが不要になるわけではない。高度なアクセス制御が必要なセンシティブなプライベートデータへのアクセスには、APIの厳密な認可構造が引き続き有効だ。MCPは「エージェントが自律的に動き回る領域」に向いており、APIは「人間が設計した制御境界を守る領域」に向いている。両者は代替関係ではなく、役割分担の関係になる。

MCPはAnthropicが2024年11月に公開した仕様で、2025年に入ってからOpenAI・Google・Microsoftがサポートをアナウンスしたことで業界標準としての地位を固めつつある。

【補足】MCPの通信レイヤーはJSON-RPC 2.0をベースとしており、トランスポートとしてStdio（ローカルプロセス間）とHTTP+SSE（リモート）の2方式が定義されている。クライアント（LLMホスト）とサーバー（ツール提供側）の役割が明確に分離されているため、既存のREST APIをMCPサーバーでラップする実装が比較的容易になっている。背景にあるのはLLMベースのエージェントが「ツール呼び出し」を前提とした設計に移行したことだ。Function CallingやTool Useが各モデルに実装されたことで、エージェントが外部システムを操作する場面が急増した。しかし各社が独自のツール統合フォーマットを持っていたため、エコシステムが断片化していた。MCPはこの断片化を解消する共通レイヤーとして機能する。

実際にMCPサーバーがバックエンドでREST APIを呼び出す実装パターンが現実的な移行経路として機能している。MCPサーバーの認証・認可標準化が次の焦点になる。現状のMCPは自己記述型の利便性を持つ一方、アクセス制御の仕様が薄い。エンタープライズ採用が進む中で、OAuth連携やスコープ制御をMCPレイヤーに組み込む動きが出てくる。

今日の傾向

GitHubがCodeQLとAIを組み合わせたハイブリッド検出をQ2パブリックプレビューとして発表し、Shell/Bash・Dockerfile・HCL・PHPというCodeQLの空白地帯をAIで埋める設計を選んだ。「AIに全部置き換える」のではなく既存の静的解析を残す判断は、Copilot Autofixが2025年に46万件のアラートを処理し平均解決時間を1.29時間から0.66時間に短縮した実績を背景にしている。

AnthropicのMCPがOpenAI・Google・Microsoftのサポートを得て業界標準化が進む一方、MCPサーバーのアクセス制御仕様の薄さが次の課題として浮上した。OpenClawのAPIキー漏洩事例が示すように、エージェントの自律的な動作がセキュリティの新しい攻撃面を生んでいる。GitHubのAI検出拡張とMCPの普及は、「AIが書き・AIが動かすコード」のセキュリティをどう担保するかという同じ問いに別の角度から向き合っている。

RustのコヒーレンスルールをめぐるNikomatsakisの「crate-level where clauses」提案と、rkyv・postcardによるserdeエコシステムの外側での特化が同時進行している。孤児ルールが「先に到達したクレートが技術的優位性とは無関係に生き残る」構造を生んでいるという指摘は、Kubernetes・OpenTelemetry・CloudEventsがCNCFのオープンスタンダードとして成熟したことで「先行者が標準を固める」という同じ力学がインフラ層でも働いていることと対応している。

Pi-HoleのDocker展開が「普通の選択肢」として記事化されたのは、2015年から存在するプロジェクトに対してではなく、スマートTV・IoTセンサーといったブラウザ拡張を入れられないデバイスの増加という2025年の文脈に対してだ。AT&T FiberのようにルーターのDNS設定を変更できないISPという制約が明示されたことで、「DNSレベルの介入が唯一の現実的な手段」という主張の射程が明確になった。

参照記事

記録日: 2026-03-24