AI Agent

Claude Code をはじめとする AI エージェントの運用で 「シークレットをどこにどう置くか」 は避けて通れない設計判断になります。Git リポジトリに暗号化したまま置ける SOPS（旧 Mozilla SOPS、現在は CNCF Sandbox プロジェクト）は GitOps と相性がよく、小〜中規模のチームや個人開発では有力な選択肢の一つです。 ただし、シェルやファイル操作の権限を持つ AI エージェントと組み合わせる場合、「AI が自分で復号して中身を覗き見・漏洩させない」 ための3つのガードレール設計が前提になります。本記事では SOPS のメリットと AI エージェント特有のリスク、そして推奨構成をまとめます。 SOPS を AI エージェント運用で使うメリット SOPS は「Git リポジトリに暗号化したまま秘匿情報を保存できる」シンプルなツールです。AWS KMS、GCP KMS、Azure Key Vault、age、PGP など、環境に合わせた暗号化バックエンドを選べます。 AI エージェントとの相性で見ると、特に次の3点でメリットがあります。 構成管理の簡素化 — 開発環境（.env など）とデプロイ環境の秘密情報を、同じ Git ワークフローで一貫管理できる diff が読みやすい — SOPS は YAML / JSON の 値だけを暗号化 し、キー（変数名）は平文で残せるため、AI エージェントが「どんな設定項目があるか」を構造として理解できる 柔軟なバックエンド — クラウド KMS から手元の age キーまで、用途に応じて使い分けられる 特に「キー名は平文・値だけ暗号化」という設計は、AI エージェントに「設定の存在は知らせるが値は見せない」運用と非常に親和性が高い構造です。 なお、マネージド型のクラウドサービスでシークレットを集中管理したい場合は、Infisical のような選択肢もあります。「Git で持つか／サービスで持つか」は採用判断のポイントになります。 AI エージェント特有のリスク 一方で、Claude Code のように Bash 実行権限を持つエージェントに SOPS を扱わせると、以下のリスクが顕在化します。 ...

Andrej Karpathy が2026年4月に公開した GitHub gist「LLM Wiki」が、公開から48時間以内に5000スターを超えた。コード一行も含まない、純粋にアイデアだけを記述したドキュメントがここまで反響を呼んだ理由はシンプルだ。「RAGの次」を具体的かつ実践的に示していたからである。 RAGとの決定的な違い 多くの人がLLMとドキュメントを組み合わせるとき、最初に試みるのが RAG（Retrieval-Augmented Generation） だ。ChatGPTのファイルアップロード、NotebookLM、LangChainで構築するベクトルDB検索 — これらはすべて「質問が来たときにドキュメントから関連部分を取ってきて回答する」という設計思想に基づいている。 この方式には根本的な問題がある。知識が蓄積されない。5つのドキュメントを横断する微妙な問いに対しても、LLMは毎回ゼロから関連箇所を探し出し、推論し直す。「矛盾」も「文脈」も「先週気づいた発見」も、次の質問では消えてしまう。 LLM Wiki が提案するのは根本的に異なるアプローチだ。 LLM が incrementally に永続的な wiki を構築・維持する。新しいソースを追加するたびに、LLM はそれを読み込んで既存 wiki に統合し、エンティティページを更新し、矛盾を記録し、進化する合成の全体を強化する。知識は毎回再導出されるのではなく、一度コンパイルされてから最新に保たれる。 この「コンパイルされた知識ベース」こそが LLM Wiki の本質である。 3層アーキテクチャ LLM Wiki は3つの層で構成される。 1. Raw Sources（生ソース） 記事、論文、画像、データファイルなど自分がキュレートしたソースドキュメントの置き場。不変（immutable） — LLMはここから読むだけで決して書き換えない。これが「真実の源泉」となる。 2. The Wiki（wiki本体） LLM が生成・維持するマークダウンファイルの集合。概要、エンティティページ、概念ページ、比較、合成。この層は LLM が完全に所有 する。あなたは読む側で、LLM が書く側だ。 3. The Schema（スキーマ） CLAUDE.md（Claude Code用）や AGENTS.md（Codex用）など、LLMに wiki の構造・規約・ワークフローを伝えるドキュメント。これが LLM を「汎用チャットボット」から「規律あるwikiメンテナ」に変える鍵だ。このファイルはあなたと LLM が協力しながら進化させていく。 3つの操作 Ingest（取り込み） 新しいソースを生コレクションに追加して、LLMに処理を依頼する。LLMはソースを読み込み、重要な情報を抽出し、wikiに統合する。一つのソースが10〜15のwikiページを更新することもある。一度に大量のソースをバッチ処理することも可能だが、Karpathy 自身は「一つずつ取り込み、要約を確認しながら進める」スタイルを好むと述べている。 Query（クエリ） wikiに対して質問する。LLMは関連ページを検索・読み込み、引用付きで回答を合成する。回答の形式は問いによって変わる — マークダウンページ、比較表、Marpスライド、matplotlibグラフなど。 重要な洞察: 良い回答はwikiに新しいページとして追記できる。「あの比較をお願いした結果」「見つけた新しい接続」— これらをチャット履歴に埋もれさせるのではなく、wikiに蓄積させることで探求が複利的に積み重なる。 ...

takt は、Claude Code や Codex などの AI コーディングエージェントのワークフローを YAML で定義できる CLI ツールです。エージェントに単にコードを書かせるだけでなく、レビューループや人間の介入ポイントを宣言的に管理することで、品質の高いアウトプットを継続的に得られるよう設計されています。 takt とは TAKT は TAKT Agent Koordination Topology の略で、ドイツ語の「拍子・指揮棒」を由来とする名前です。オーケストラの指揮者のように複数の AI エージェントを統率するというコンセプトが込められています。 GitHub: https://github.com/nrslib/takt 言語: TypeScript スター数: 952（2026年4月時点） ライセンス: MIT 対応エージェント: Claude Code、Codex、OpenCode、Cursor、GitHub Copilot CLI なぜ takt が必要か AI コーディングエージェントを使う上で重要なのは、ワークフローの設計です。エージェントに「コードを書いて」と指示するだけでは、品質にばらつきが生じます。takt は以下の課題を解決します: レビューループの自動化: 実装 → レビュー → 修正 のサイクルを自動で回す 再現性の確保: 実行パスを YAML で宣言するため、チーム間で同じ品質プロセスを共有できる マルチエージェント対応: 異なるペルソナ・権限・レビュー基準を持つ複数エージェントをオーケストレーション 完全なトレーサビリティ: 全ステップを NDJSON でログに記録 インストールと基本的な使い方 1 npm install -g takt 設定ファイル ~/.takt/config.yaml を作成してプロバイダーを指定します: ...