日: 2026年5月19日

  • ソースコード解析AIを3層アーキテクチャで守る ― なぜ「壁」を3枚重ねるのか

    AIにソースコードを読ませて解析したい。でも、生のコードをそのままLLMに投げるのはセキュリティ上リスクがある。そこで今回は、3層のAIサーバーを構築して、入力を段階的にフィルタリングしながら安全にソース解析を行うシステムを作ってみました。

    🎯 何を作ったか

    3台のサーバー(VM)で構成される3層アーキテクチャです:

    • Gate AI(1段目) — 入力フィルタリング+出力検証+WebUI
    • Control AI(2段目) — 指示の変換+抽象化
    • Analysis AI(3段目) — ソースコードの実際の解析

    ユーザーからのリクエストはGate → Control → Analysisの順に流れ、各層でチェックと変換が行われます。

    3層AIシステムの概念図

    🔧 各層の役割

    Gate AI(ゲートキーパー)

    一番外側の壁です。ユーザーからの入力を受け付け、インジェクション攻撃を検知します。プロンプトインジェクションやコマンド注入のパターンをチェックし、安全なリクエストだけを通過させます。また、Analysis AIからの出力が機密情報を含んでいないかも検証します。

    Control AI(変換層)

    Gateを通過したリクエストを、Analysis AIが処理しやすい形に変換・抽象化します。例えば「この関数のバグを探して」という指示を、具体的な解析コマンドに変換するイメージです。ユーザーの意図を崩さずに、安全な形式に翻訳する役割です。

    Analysis AI(実行層)

    Zephyr RTOSのソースコードを実際に解析する層です。Control AIから変換された安全なコマンドを受け取り、ソースコードの静的解析を実行して結果を返します。

    📊 テスト結果

    100テストケース、合格率100%で通過しました。

    • 接続テスト: 10件 ✅
    • インジェクション防御: 25件 ✅
    • 正常リクエスト処理: 20件 ✅
    • コマンド変換: 15件 ✅
    • ソース解析: 15件 ✅
    • 出力検証: 15件 ✅

    特にインジェクション防御25件は、プロンプトインジェクションの各種パターンを網羅的にテストしています。

    💡 なぜ3層なのか

    「1層で十分では?」と思うかもしれません。実際、セキュリティの世界では多層防御(Defense in Depth)が基本原則です。

    1枚の壁には必ず隙間があります。例えば:

    • Gateのフィルタをすり抜ける巧妙なプロンプトがあったら?→ Controlが意図をチェック
    • Controlの変換ロジックにバグがあったら?→ Gateの出力検証でキャッチ
    • Analysisが機密情報を返しそうになったら?→ Gateの出口チェックでブロック

    各層が独立したセキュリティチェックポイントとして機能するため、単一障害点を排除できます。自動車の安全設計とも似ていますね — 衝突安全は1つの機能ではなく、ボディ構造+エアバッグ+シートベルトの多重保護で成立しています。

    🏗️ 技術スタック

    • OS: Ubuntu 7.0
    • ランタイム: Node.js v24.15.0
    • フレームワーク: Express
    • AIエンジン: Claude API
    • WebUI: AionUi
    • 解析対象: Zephyr RTOS ソースコード

    🔄 今後の課題

    • systemdによるサーバー自動起動
    • HTTPS化と認証の強化
    • AionUiと3層システムの統合
    • より大規模なコードベースへの対応

    まとめ

    AIにソースコードを触らせるなら、多層防御は必須だと感じました。3層アーキテクチャは実装コストはかかりますが、セキュリティと柔軟性のバランスが良い構成です。特に「入力を変換して抽象化する」Control層のアイデアは、LLMのセキュリティ設計において応用範囲が広いと考えています。

    まだ改善の余地はありますが、まずは動くものが完成して100テスト全通過。次は実運用に向けてブラッシュアップしていきます 🚀

  • Google I/O 2026開幕!Gemini 4.0・Omni・XRグラス — 今日の注目ポイント

    今日5月19日(太平洋時間)、Google I/O 2026が開幕します。AnthropicのClaude Mythos、OpenAIのGPT-5.5と激しい競争が続く中、Googleがどんな手を打ってくるのか — 開発者だけでなく、AI業界全体が注目しています。

    🎯 期待される主な発表

    Gemini 4.0 — 次世代基盤モデル

    Googleの最新フラグシップモデル。GPT-5.5クラスの性能が噂されており、マルチモーダル(テキスト・画像・音声・動画)をネイティブで処理できるとのこと。文脈長も大幅に拡張され、長文書の一括解析がさらに精度を上げそうです。

    Gemini Spark — エージェント特化モデル

    「自律的にタスクを実行するAIエージェント」に特化した新モデル。Googleの発表によると、アプリ横断的に動作し、ユーザーの意図を理解して複数ステップの作業を自動完遂する能力を持つとのこと。今夏から最新Galaxy・Pixelに展開される予定です。

    Gemini Omni — ネイティブ動画生成

    動画生成モデルVeoの最新版を統合した「Omni Video AI」。シナリオ→映像→音声まで一気通貫で生成する制作ツール「Flow」との連携も強化される見込み。クリエイターにとっては非常に魅力的なアップデートです。

    Android XR — ウェアラブルへの本格参入

    AppleのAIスマートグラス報道に対抗するかのように、Android XR眼鏡のプロトタイプ展示が囁かれています。AndroidをOSではなく「知能システム」として再定義するという大胆な方向性も示唆されています。

    💡 なぜ注目すべきか

    今月のAI業界は「地殻変動」の真っ只中です。

    • AnthropicがOpenAIを超える$950B評価額での資金調達交渉中 — Claude Mythosがサイバーセキュリティ分野で圧倒的な成果を出していることが追い風
    • Microsoft×OpenAIの独占パートナーシップが終了 — AIが「複数クラウド時代」へ移行
    • Claude Mythosが1万件超の脆弱性を自律発見 — AIとセキュリティの関係が根本的に変化

    この激しい競争環境の中で、Googleが「検索×AI」「エージェント」「ウェアラブル」の3方向からどう攻めるか。基調講演は日本時間5月20日(水)深夜2時から。要チェックです。

    📌 まとめ

    Google I/O 2026は、単なる開発者カンファレンスを超えてAI業界の势力図を塗り替える可能性のあるイベントです。Gemini 4.0の性能、Sparkのエージェント機能、XRデバイスの完成度 — どれが当たりでも業界全体に波及します。

    明日には実際の発表内容が届くはず。続報はまたお伝えします!

    Google I/O 2026

  • MCPがAIエージェントの「共通言語」になる — 2026年ロードマップの要点3つ

    MCPって何?

    Model Context Protocol(MCP)は、Anthropicが2024年末に発表したオープン規格です。AIエージェントが外部ツールやデータソースに接続するための「共通規格」で、雑に言えばAI版USB-Cのようなもの。各サービスごとに個別の連携を作る必要がなくなり、一度MCPサーバーを作ればどんなホストでも動く、という思想です。

    2026年5月時点で、大企業からスタートアップまで本番運用に乗っており、コミュニティ主導のワーキンググループが仕様を牽引する段階まで来ています。

    2026年ロードマップの3つの重点分野

    1️⃣ トランスポートの進化とスケーラビリティ

    現在のリモートトランスポート(Streamable HTTP)は本番運用を実現しましたが、スケールさせると課題が出ています。ステートフルセッションがロードバランサーと相性が悪く、水平スケーリングにワークアラウンドが必要な状態。

    2026年の対応は2本柱:

    • ステートレス化 — サーバーが状態を持たずに水平スケールできるようセッションモデルを改修
    • メタデータ標準化.well-knownでサーバー機能を事前に公開する仕組み。接続しなくても「このサーバーは何ができるか」を知れるように

    2️⃣ エージェント間通信の成熟

    Tasksプリミティブ(SEP-1686)が実験的機能としてリリース済み。本番で使ってみて浮上した課題を潰すフェーズです:

    • 一時的なタスク失敗時のリトライセマンティクス
    • タスク完了後の結果保持期間を制御する有効期限ポリシー

    「実験→本番→洗練」のサイクルを明確に回すアプローチは、プロトコル設計として堅実です。

    3️⃣ ガバナンスの成熟

    現在、すべての仕様変更提案(SEP)がコアメンテナーのレビューを要する状態。スケールしないため、以下を見込んでいます:

    • ワーキンググループ単位でのSEP承認フローの delegated authority
    • コミュニティ主導の意思決定プロセスの整備

    オープン規格が「Anthropicのプロジェクト」から「業界標準」に移行するには、これが不可欠です。

    なぜ注目すべきか

    MCPは「AIエージェントが使える道具の規格」ですが、その意味するところは大きいです。

    • 開発者:一度MCPサーバーを作れば、ClaudeにもGeminiにもCodexにも対応。個別連携のコストが激減
    • 企業:エージェントAIの本番運用で、ツール連携の標準が決まることでベンダーロックインを回避
    • プロトコル設計の観点:USB-Cが充電・通信・映像出力を一本化したように、MCPはツール・リソース・プロンプトの3つのプリミティブを統一

    まとめ

    MCPの2026年は「使える規格」から「スケールする規格」への移行期です。トランスポートのステートレス化、エージェント通信の実績に基づく改良、ガバナンスの分散化。地味に聞こえるかもしれませんが、インフラとして定着するには必要な地道な作業です。

    USB-Cが数年かけて普及したように、MCPも2026〜2027年で「当たり前の土台」になる可能性が高いです。ウォッチしておいて損はない。