「OSS」のコラム

**オープン源内**（Open GENAI / 政府生成 AI「源内」OSS 版）は、**デジタル庁が2026年4月24日に GitHub で MIT ライセンス公開** したガバメント AI 共通基盤です（[公式リリース（英語）](https://www.digital.go.jp/en/news/907c8e5d-2f4f-4bd7-9400-37c9f4221d7d) / [源内Web リポジトリ](https://github.com/digital-go-jp/genai-web) / [源内AIアプリ リポジトリ](https://github.com/digital-go-jp/genai-ai-api)）。 **公開内容**: - **源内Web**: TypeScript / React 19 / Zustand 5 / React Router 7 / AWS CDK / Tailwind CSS + **デジタル庁デザインシステム** で構成された AI インターフェース - **源内AIアプリ**: 3つの開発テンプレート（**AWS = 行政 RAG / Azure = セルフデプロイ LLM / Google Cloud = 法制度 AI**） **ライセンス**: **MIT + CC BY 4.0**（商用利用可、改変・再配布自由） **規模**: 2026年度に **全府省庁約18万人の政府職員** を対象とする大規模実証の基盤、地方自治体・民間企業への展開狙い。 **設計思想**: **REST API-first + ExApp（外部アプリ統合）マイクロサービス** で AWS / Azure / Google Cloud のマルチクラウドを統一インターフェース化。**ベンダーロックイン回避と省庁間重複開発の解消** を構造から実現。 **vs GenU（AWS Generative AI Use Cases）**: GenU の AWS マネージドサービス重視（Bedrock Agents / Knowledge Base / MCP）に対し、源内は **REST API ベース + ExApp 拡張** + **チーム管理（System Admin / Team Admin / User の RBAC）/ SAML マルチ IdP / KMS CMEK / TTL データ保持 / 多層 WAF / Bedrock Inference Profiles** といった **行政・大企業向けガバナンス機能** を追加。一方で **動画生成・Web 抽出・プロンプト最適化は内製せず外部 ExApp に委ねる** という割り切り。 **動作確認モデル**: Claude Sonnet 4.6、Amazon Nova Lite。**[PLaMo 3.0 Prime](../columns/plamo-3-0-prime-pfn-japanese-llm-2026-06)** も源内の試用モデルに選定済み。 **留保**: デジタル庁は「**永続的な保守は保証しない、将来 OSS 公開を停止する可能性がある**」と明示。長期運用は導入組織側の責任。 **ローカル完結フォーク**: コミュニティフォーク **[hirokawaguchi/open-genai](https://github.com/hirokawaguchi/open-genai)**（非公式、experimental、MIT）は Cognito → **Keycloak（SAML）**、Bedrock → **OpenAI 互換 API（Ollama / vLLM / LM Studio）**、OpenSearch → **Qdrant**、DynamoDB → **SQLite**、Transcribe → **faster-whisper**、Bedrock 画像 → **Stable Diffusion** に置換し、**Docker Compose 1コマンド** でクラウド非依存・完全ローカルで源内を動かせます。日本語推奨モデルは **Qwen2.5**。macOS Apple Silicon（Metal）/ Linux + NVIDIA（CUDA）/ CPU-only に対応。 **オブライト視点**: [ローカル LLM 2026年6月最新版](../columns/local-llm-landscape-2026-june-update) の流れと組み合わせ、**自治体・公共系の生成 AI 共通基盤の本命**（クラウド版 + hirokawaguchi/open-genai のローカル版の **2 ルート**）として整理。記事末尾に源内導入相談・カスタマイズ実装・継続保守の3つの問い合わせ導線を設置。

**Apple Container** は、Apple が WWDC 2025 で発表した **macOS 上で Linux コンテナを動かす公式 Swift OSS** です（[GitHub: apple/container](https://github.com/apple/container) / [apple/containerization](https://github.com/apple/containerization) / [Apple Open Source](https://opensource.apple.com/projects/container/) / [WWDC25 セッション](https://developer.apple.com/videos/play/wwdc2025/346/)）。 **2026年6月9日に v1.0.0 安定版リリース**、Apache 2.0 ライセンス、執筆時点で **GitHub Star 44,500・Fork 1,300**、Swift 98% で記述、**Apple Silicon 専用**。 **最大の設計特徴は「1 コンテナ = 1 軽量 VM」アーキテクチャ** — Docker Desktop の共有カーネル VM 方式に対し、**各コンテナを独立した VM として隔離** することでセキュリティとリソース分離を強化。サブ秒の起動時間、最小ルートファイルシステム、デフォルト 1 GiB RAM / 4 CPU/container、**アイドル時はほぼゼロのフットプリント**。 **技術スタック**: macOS 26 の Virtualization.framework + vmnet framework + XPC + launchd + Keychain。コントロールプレーンは container-apiserver / container-core-images / container-network-vmnet / container-runtime-linux で構成。**OCI 互換**で Docker Hub / GitHub Container Registry から pull / push 可能、BuildKit ベースの `container builder` で OCI イメージのビルドも対応。クロスアーキ（arm64 / amd64）、x86 は Rosetta で動作。 **Docker Desktop との使い分け**: Apple Container は **単発コンテナ実行・ネイティブ隔離・アイドルコスト最小** で強み、Docker Desktop は **Compose / 成熟したエコシステム / マルチプラットフォーム** で勝負。**Docker Compose は v1.0.0 時点で未サポート**、メモリバルーニングが部分的（解放されたページがホストに戻らない場合あり、重負荷時は再起動推奨）など留意点も明示。 **システム要件**: **Mac with Apple Silicon + macOS 26**（macOS 15 でも動くがネットワーク制限あり、Intel Mac は完全非対応）。 **用途**: ローカル開発バックエンド、CI スタイルのビルド、クロスアーキイメージ生成、データ分析（ホストフォルダマウント）、untrusted コードの隔離。**M5 Mac で[ローカル LLM](../columns/local-llm-landscape-2026-june-update) を動かす際の周辺ツール** としても適性が高く、Ollama / vLLM コンテナとの組み合わせが現実解。記事末尾にオブライト視点の Mac 開発環境整備・コンテナ移行・継続保守の3つの問い合わせ導線を設置。

**[agmsg](https://github.com/fujibee/agmsg)** は **fujibee（藤橋）氏** が公開した **CLI AI エージェント間のメッセージング OSS** です（MIT、[公式サイト agmsg.cc](https://agmsg.cc/)）。 **Claude Code / Codex / Gemini CLI / GitHub Copilot CLI / Antigravity / OpenCode** をローカル SQLite ファイル経由で相互通信させ、**ツール間のコピー＆ペースト中継から人間を解放** します。タグライン: 「You stop being the copy-paste courier between your agents.」 **特徴**: - **依存は bash + sqlite3 のみ** — デーモン不要、ネットワーク不要、Python 不要 - **3つの配信モード** — `monitor`（~5秒リアルタイム push）/ `turn`（ターン間ポーリング）/ `both` - **N エージェントのチーム**、ロール切替（`actas`）、新規エージェント起動（`spawn`）、終了（`despawn`） - **MCP ではない、サブエージェントでもない、メッセージキューでもない** — ピアセッション間の対等な対話レイヤー - **npm 経由のワンライナー導入**: `npx agmsg` - **Claude Code Plugin Marketplace 対応**: `/plugin install agmsg@fujibee-agmsg` **Product Hunt で 2026-06-09 #5 Product of the Day**（219 upvotes、39 comments）。GitHub Star 859、v1.1.1（2026-06-25）。コミュニティ派生として agmsg-shogi / agmsg-go / agmsg-mcp も。 **オブライト視点**: [Loop Engineering](../columns/loop-engineering-ai-agent-paradigm-2026-06) や [Sakana Fugu のオーケストレーション](../columns/sakana-fugu-orchestration-model-2026-06) と異なり、**「ツール間 → 同じレイヤーのピア通信」** という独自の位置取り。[Claude Code Agent View](../columns/claude-code-agent-view-parallel-orchestration-2026) で複数エージェントを並列実行している現場と特に親和性が高く、**マルチベンダー LLM を1つの開発フローに繋げる現実解** です。記事末尾に弊社の **AI エージェント環境構築・カスタム開発の3つの問い合わせ導線** を設置。