ID:82657さん

# Hyground — インシデント対応自動化のためのエージェント型AIシステム ## 【チーム情報】 ### チーム規模 - 立ち上げ時: 4名 - ピーク時: 10名 ### 構成 #### 立ち上げ時 - プロダクトオーナー: 2名 - 開発者: 2名（自身を含む） #### ピーク時 - プロダクトオーナー: 2名 - 開発者: 5名（自身を含む） - インターン: 3名（オーバーシーも担当） ### 役割 AIエンジニア兼AIアーキテクト。 以下を主導： - エージェント設計 - 実装 - 本番デプロイ - 運用監視 後半フェーズでは以下も担当： - インターン3名の技術指導 - コードレビュー - オンボーディング支援 --- # 【概要】 社内SREチームが直面する「インシデント応答に30分以上かかる」課題に対し、LLMとエージェントフレームワーク（LangGraph、Google ADK）を活用した自律型インシデント対応システムを開発。 Kubernetesクラスター・Prometheusメトリクス・Lokiログを自然言語で調査・診断できるエージェントシステムを構築した。 --- # 【開発・実装した機能】 ## ■ マルチエージェント協調フレームワーク - 自律的インシデント解決フレームワークを設計・実装 - 複数専門エージェントが連携して調査・診断を実施 ## ■ Kubernetes調査エージェント - `kubectl` と連携 - Kubernetesクラスター状態を取得 - Pod・Deployment・Node 状態を分析 ## ■ Prometheusメトリクス問い合わせエージェント - Prometheusクエリを自然言語から生成 - CPU / Memory / Latency / Error Rate などを分析 ## ■ Lokiログ解析エージェント - Lokiログストリームを横断検索 - エラーパターンや異常挙動を抽出 ## ■ 自然言語チャットインターフェース - SRE担当者が自然言語で調査依頼可能 - インシデント状況を対話形式で確認可能 ## ■ LangGraphオーケストレーション - LangGraph によるエージェント制御 - 状況に応じて必要エージェントを動的呼び出し ## ■ 本番デプロイ基盤 - Helm Chart による本番デプロイ - Kubernetes環境への再現性ある配備を実現 ## ■ 監視・SLO追跡 - Grafana ダッシュボード構築 - 応答時間・成功率・自動化率・SLOを可視化 --- # 【課題・問題点】 - SREチームの応答時間が30分以上かかっていた - 夜間・休日オンコール負荷が深刻化 - 一般的なインシデント（Pod再起動・メモリ不足・設定ミス等）が多数を占めるにもかかわらず、毎回同じ調査手順を手動実施していた - 純粋なLLM呼び出しだけではリアルタイムなクラスター状態を取得できない - LLMの誤判断による誤操作（誤デプロイ・誤削除）のリスクが存在 - 99.9% SLO を維持したまま新システムを本番投入する必要があった - 後半フェーズではチーム拡大とインターン受け入れに伴い、知識移転とコード品質維持が課題となった --- # 【工夫した点・使用技術】 ## ■ エージェント分割設計 単一の巨大エージェントではなく、責務ごとに専門エージェントを分離： - Kubernetes担当 - メトリクス担当 - ログ担当 LangGraph上のオーケストレーターが必要に応じて呼び出す構成にすることで： - 信頼性向上 - テスト容易性向上 - デバッグ容易性向上 を実現。 ## ■ Human-in-the-loop原則 - 自動化率は60〜75%に制限 - 破壊的操作は必ず人間承認を要求 対象例： - 削除 - 再起動 - ロールバック 安全性を優先した設計とした。 ## ■ 段階的ロールアウト ### Phase 1 - 読み取り専用調査タスクのみ本番投入 ### Phase 2 - 信頼確立後に操作タスクを段階的解禁 リスクを抑えつつ運用移行を実施。 ## ■ 本番インフラ設計 ### Kubernetes + Helm - 再現性あるデプロイ - 環境差異を最小化 ### Grafanaダッシュボード 以下を継続監視： - 応答時間 - 自動化率 - 成功率 - SLO達成率 ## ■ チーム拡大期の知識移転 インターン3名の指導も担当。 実施内容： - エージェントアーキテクチャ資料整備 - オンボーディング支援 - ペアプロ体制構築 - コードレビュー運用 チーム拡大後も品質維持可能な開発体制を構築。 ## ■ 技術スタック ### AI / Backend - Python - LangGraph - Google ADK - LangChain ### Infrastructure - Kubernetes - Helm - Prometheus - Loki - Grafana ### Cloud - AWS - Azure --- # 【成果】 - 平均インシデント応答時間を - 30分以上 → 5分未満 - 85〜95%削減 - 一般的インシデントに対する - 自動解決率60〜75%を達成 - 本番環境にて - 99.9%アップタイムを維持 - 夜間・休日オンコール負荷を大幅軽減 - AWS Community Meetups にて発表 - Darmstadt - Bonn - 参加者100名超 - アーキテクチャ・運用知見を共有 - インターン3名がプロジェクト終了時には独立して機能開発可能な水準まで成長

# Swarm Orchestrator — マルチエージェント合意形成システム ## 【チーム情報】 - 個人プロジェクト（OSS、1名体制） - 設計・実装・PyPI公開・ドキュメント全般を一人で担当 --- # 【概要】 MAKER論文の原則（冗長実行 + 投票）をコード生成に適用したCLIツールを設計・実装し、PyPIに公開。 複数のClaude Codeエージェントを Schaltwerk 経由で独立した git worktree 上に並列展開し、それぞれが独立してタスクを実装した後、エージェント間のクロス投票によって最良の解を採用する「合意形成型コード生成」の仕組みを構築した。 --- # 【開発・実装した機能】 ## ■ タスク自動分解 - Claude CLI を使って複雑なタスクを独立した複数のサブタスクへ分解 - API key不要 - 既存のClaude Code認証を再利用 ## ■ エージェント並列実行 ### Schaltwerk連携 - 各サブタスクに対してN体のエージェントを並列展開 - デフォルト3体、設定変更可能 - 各エージェントは独立した git worktree 上で動作 ## ■ MCPベース完了シグナリング - 各エージェントが MCPツール経由で完了通知 - git diff を添付して結果提出 ## ■ クロス投票メカニズム - 全エージェントが他のすべての実装をレビュー - 最良の実装へ投票 ## ■ 多数決による自動マージ - 最多得票の実装を勝者として採用 - `--auto-merge` オプションでメインブランチへ自動マージ ## ■ マルチプロジェクト対応 - 絶対パスベースの state ファイルを利用 - 複数プロジェクト間で干渉せず同時運用可能 ## ■ CLIコマンド群 ### 提供コマンド - `swarm init` - プロジェクト初期化 - `swarm run` - タスク実行 - `swarm decompose` - 分解プレビュー - `swarm status` - セッション状態確認 ## ■ 言語非依存設計 以下を含む任意プロジェクトで利用可能： - Python - JavaScript - Go - Rust ## ■ グローバルCLI配布 以下インストール方式に対応： - pipx - uv tool - pip 仮想環境アクティベーション不要で利用可能。 --- # 【課題・問題点】 - 単一エージェントによるコード生成は、確率的にハルシネーションやバグを含む - 信頼性が用途によっては不十分 - 複数エージェントを単純並列実行しても以下2点が未解決だった - 同一ファイルへの編集競合 - どの解を採用すべきかの判断 - 別途API keyを要求すると導入障壁が高い - Python以外のプロジェクトでは仮想環境管理が煩雑 - Claude Code CLIユーザーが追加設定なしで利用できる設計が必要だった --- # 【工夫した点・使用技術】 ## ■ 分離環境による競合の構造的排除 - Schaltwerk（macOS）の管理する独立 git worktree を利用 - 各エージェントを完全分離 - 同一ファイルへの並列編集競合をアーキテクチャレベルで排除 ## ■ MAKER原則の実装 ### 冗長実行 + 多数決 - 複数エージェントによる並列実行 - クロスレビューによる投票 これにより、単一エージェントのハルシネーションを統計的に軽減。 また、エージェント自身が他者の実装をレビューすることで客観的評価を組み込んだ。 ## ■ 既存認証の活用 - Claude Code CLI の既存認証情報を再利用 - Max / Pro サブスクリプションをそのまま利用可能 - 新規API key発行不要 必要に応じて Anthropic API にフォールバック可能。 ## ■ MCPサーバー統合 - Swarm自体がMCPサーバーとして動作 - Claude Code セッションから直接呼び出し可能 ## ■ タスク状態の永続化 - `.swarm/state.json` にセッション状態を保存 - 中断・再開・デバッグに対応 ## ■ グローバルCLI設計 - pipx / uv tool による分離インストール - Python環境が存在しないプロジェクトでも `swarm` コマンドを利用可能 ## ■ 技術スタック ### Core - Python 3.11 / 3.12 / 3.13 - Claude CLI - Schaltwerk - MCP - Git worktrees ### Tooling / Packaging - PyPI パッケージング - uv - pytest - ruff --- # 【成果】 - PyPI に公開 - `pip install swarm-orchestrator` - `pipx install swarm-orchestrator` - ゼロAPI key要件で Claude Code 利用者が即時導入可能 - 個人プロジェクト15件以上で並列エージェントワークフローを実運用 - GitHub 公開 - `github.com/rayen-faleh/swarm-orchestrator` - MIT License で公開

# CLIDE — 人間のような記憶と進化する性格を持つ自律型AIエージェント ## 【チーム情報】 - 個人プロジェクト（OSS、1名体制） - 設計・実装・テスト・ドキュメント・公開まで全工程を一人で担当 --- # 【概要】 ローカル環境で常時稼働する完全自律型AIエージェント。 フルスタック構成（Python 3.12+ / FastAPI バックエンド + Vue.js 3 / TypeScript フロントエンド）でゼロから設計・実装。 「永続的な進化する性格」「自律的な思考サイクル」「人間に近い記憶構造（A-MEM）」「自ら目標を設定し追跡する能力」を備え、再起動を跨いで状態を保持し続ける「生きた」エージェントを目指した。 --- # 【開発・実装した機能】 ## ■ A-MEM（長期記憶システム） - Zettelkasten方式の長期記憶システム（SQLite + ChromaDB） - 各記憶を原子的なZettelとして保存 - リンクによる知識グラフを構築 ## ■ 状態管理 ### 5状態の有限状態マシン - `SLEEPING` - `IDLE` - `THINKING` - `CONVERSING` - `WORKING` 状態遷移ルールにより矛盾するオペレーションを排除。 ## ■ 自律的思考システム - 設定可能な間隔（デフォルト5分）で `THINKING` 状態へ遷移 - メモリ・性格・目標・意見を統合した自己リフレクションを実行 ## ■ 性格・感情システム ### 性格進化システム 5つの特性が漸進的に変化： - curiosity - warmth - humor - assertiveness - creativity 1インタラクションあたり最大0.02の変化幅で制限。 ### 12状態のムードシステム 以下の状態間をグラデーション的に遷移： - neutral - curious - excited - contemplative - playful - focused - content - melancholy - frustrated - amused - inspired - tired ## ■ 目標管理システム - 自律的思考中に新規目標を生成（最大同時5件） - 進捗追跡 - 停滞した目標の自動失効 ## ■ 意見ストア - トピックごとに stance と confidence を持つ意見を蓄積 - 最高信頼度の上位5件をシステムプロンプトへ注入 ## ■ MCP統合 - stdio JSON-RPCで外部MCPサーバーと通信 - `tool_choice=auto` による非ストリーミングエージェンティックループ（最大10反復） ### Smallville MCPサーバー Stanford/Google の Generative Agents 論文の村シミュレーション用 MCPサーバーを内蔵実装。 実装ツール例： - observe_village - talk_to_villager - share_memory - その他含め計8ツール ## ■ LLM統合 ### マルチプロバイダー対応 LiteLLM経由で以下に対応： - Ollama - Anthropic - OpenAI - Gemini - Mistral - NVIDIA Build 推論トークン（`reasoning_content`）の自動ハンドリングを実装。 ## ■ コスト・トークン管理 - セッションごとのコスト計算 - 日次トークンバジェット（デフォルト50万） - 80%警告閾値 ## ■ ライブ設定編集 - システムプロンプト - 性格特性 を Settings UI から即時編集可能（バックエンド再起動不要）。 ## ■ WebSocketリアルタイム可視化 以下3画面構成： - Chat - Dashboard - Settings 思考ストリーム・エージェント状態・メモリグラフを可視化。 --- # 【課題・問題点】 - 既存のAIエージェントは stateless なものが多く、会話終了とともに記憶を失う - 長期的に成長する「生きた」エージェントには独自の記憶アーキテクチャが必要だった - 単純なコサイン類似度検索では文脈的に関連する記憶を引き出せない - 自律的思考中に特定話題へ固執する「トンネルビジョン」現象が発生 - スケジューラが思考サイクルより速く発火すると重複実行や暴走が発生する可能性 - 性格変化の振れ幅が大きいと人格的一貫性を失う - 複数LLMプロバイダー間でレスポンス形式・推論トークン・並行制御・タイムアウト仕様が異なる - ローカルLLM（Ollama）はクラウドAPIより推論速度が遅く、長いタイムアウト管理が必要 --- # 【工夫した点・使用技術】 ## ■ A-MEM 二段階処理パイプライン ### Step 1 新規経験を Zettel 化する際、LLMで以下を抽出： - summary - keywords - tags - context - importance ### Step 2 直近20件の既存 Zettel と比較し： - related_to - contradicts - elaborates - caused_by - similar_to などの関係タイプと強度スコアを付与してリンク生成。 ## ■ 活性化拡散による記憶想起 - ベクトル類似度検索で上位N件を取得 - リンク強度0.5超の接続先 Zettel も追加取得 これにより、直接一致しない文脈的関連知識も想起可能にした。 ## ■ トンネルビジョン対策 - 直近6回の思考トピックを追跡 - 同一トピックが3回以上出現した場合は強制的に別トピックへ遷移 - 2回時点でソフトナッジを実施 ## ■ 思考連鎖設計 各思考に `follow_up` フィールドを保持し、次サイクルの記憶想起クエリを seed。 これにより、一貫性あるリフレクション連鎖を形成。 ## ■ Skip-if-busy + セマフォ - スケジューラ発火時に `IDLE` 状態でなければスキップ - `_thinking_in_progress` フラグでオーバーラップ防止 ## ■ 段階的性格変化の安全設計 - 1インタラクションあたり最大0.02の変化制限 - ムード遷移にグラデーションを導入 突発的な人格変化を防止。 ## ■ LiteLLM 抽象化 - プロバイダー差異をLiteLLMで吸収 - reasoning_content の自動キャプチャ - 並行コール数2のセマフォ - 10分タイムアウト - レートリミット時のグレースフル処理 ## ■ TDD 徹底 - 総計424テスト - バックエンド: 365 - フロントエンド: 59 品質管理： - mypy strict - ruff - eslint を全面適用。 ## ■ 技術スタック ### Backend - Python 3.12+ - FastAPI - SQLite (aiosqlite) - ChromaDB - LiteLLM - MCP (stdio JSON-RPC) ### Frontend - Vue.js 3 - TypeScript ### Tooling / Infra - uv - pytest - vitest - ruff - mypy --- # 【成果】 - OSS公開（GitHub: github.com/rayen-faleh/clide） - MIT License で公開 - 単一プロバイダー依存を排除 - Ollama（完全オフライン）〜 Anthropic / OpenAI / Gemini / Mistral / NVIDIA まで同一コードで動作 - 自律的思考サイクルの安定運用を確認 - トークン消費 - トピック分布 - 長時間稼働 が想定範囲内で推移 - 「記憶・性格・自律性・ツール統合」を備えたAIエージェント設計の参照実装として公開

# Agentic Coding Adoption & Mercedes-Benz Migration Service ## 【チーム情報】 ### 全社的取り組み - MaibornWolff Agentic Modernization Guild（10名以上） ### Mercedes-Benz案件 - 立ち上げ時: 3名 - ピーク時: 8名 ### 構成 #### 立ち上げ時 - プロジェクトリード: 1名 - シニア開発者: 1名 - 自身 #### ピーク時 - プロジェクトリード: 1名 - シニア開発者: 3名 - スクラムマスター: 1名 - 開発者: 5名（自身を含む） ### 役割 AIエンジニア / Agentic Coding推進担当。 以下を担当： - 社内外の知識移転 - Agentic Coding導入推進 - Mercedes-Benz案件の実装 - ワークフロー標準化 - 技術共有・教育 --- # 【概要】 社内エンジニアおよび顧客企業チームに対し、Claude Codeを中心とした Agentic Coding 手法の実用導入を推進。 並行して、Mercedes-Benz向けプレス工場計画システム再構築案件において、見積もり12週間相当だったDBマイグレーションサービス全体を Agentic Coding を活用して4日間で再構築。 社内におけるAI駆動開発のリファレンス実例として活用された。 --- # 【開発・実装した機能】 ## ■ Claude Code活用ワークショップ ### 社内向け - 社内エンジニア向けワークショップを複数回開催 - Agentic Coding の実践導入を支援 ### 顧客向け - 顧客チーム向けワークショップを共同開催 - 実プロジェクトベースで導入支援 ## ■ 月次AI動向セッション - 社内エンジニア50名超を対象 - LLM・エージェントシステム・最新研究を共有 ## ■ Mercedes-Benz向けDBマイグレーションサービス再構築 ### 技術要素 - C# - .NET - Domain Driven Design 既存サービスを再設計・再構築。 ## ■ GitHub Actions CI/CD統合 - GitHub Actions パイプラインへ統合 - 自動テスト・CI/CDフローを構築 ## ■ 並列Claude Codeワークフロー - 複数 Claude Code セッションを並列運用 - タスク分割による高速実装フローを構築 --- # 【課題・問題点】 - 多くのエンジニアが生成AIを「ChatGPTレベルのおもちゃ」と認識しており、本番コード生成への信頼が低かった - 「AIが生成したコードを誰がレビュー・検証するのか」という品質懸念が存在 - Mercedes-Benz案件では、既存DBマイグレーションサービスがチームニーズに適合しておらず、12週間規模の手動再構築が計画されていた - スライドや座学のみでは説得力が弱く、実例による証明が必要だった - ピーク時8名体制では Agentic Coding 習熟度にばらつきがあり、ワークフロー統一が課題となった --- # 【工夫した点・使用技術】 ## ■ 実例先行アプローチ 評論や啓蒙ではなく、まず Mercedes-Benz案件で： - 12週間相当のサービスを - 4日間で再構築 という実績を提示。 「動く成果物」を先に示すことで、議論の土台を構築した。 ## ■ 検証レイヤーの可視化 ワークショップでは以下を必ずセットで提示： 1. AIがコード生成 2. テスト実行 3. レビュー 4. カバレッジ確認 「AIが書いた」だけで終わらせず、品質保証フロー全体を可視化することで懸念へ対応。 ## ■ 段階的カリキュラム設計 ### 基礎 - 効果的プロンプト - タスク分解 ### 応用 - 複数Claude Codeセッション並列運用 - CI/CD統合 - 大規模タスク分割 段階的に学習できる構成を設計。 ## ■ 並列セッション運用 - 単一セッションでは時間がかかるタスクを分割 - 複数 Claude Code セッションで並列実行 このワークフローを開発・実演。 後に、この知見が OSSプロジェクト「Swarm Orchestrator」の設計思想へ発展。 ## ■ 継続的情報共有 - 月次AI動向セッションを継続開催 - LLM・Agentic Systems・最新研究を継続共有 ワークショップ後も関心と知識更新を維持。 ## ■ ワークフロー標準化 Mercedes案件ピーク時には以下をドキュメント化： - Claude Code利用方法 - タスク分解パターン - レビュー基準 - 開発フロー チーム全体で同レベルの生産性を出せる体制を構築。 ## ■ 技術スタック ### AI / Development - Claude Code - C# - .NET - Domain Driven Design ### Quality / CI - ユニットテスト - GitHub Actions - GitHub Workflows - CI/CD --- # 【成果】 - Mercedes-Benz案件にて - 見積もり12週間相当 → 4日間で完遂 - 営業日換算で約15倍の効率化 - 社内複数チームがAI支援開発を日常ワークフローへ採用 - 社内に Agentic Modernization Guild が発足 - AI駆動開発を推進する専門組織として制度化 - 自身も同Guildへ参加 - 顧客企業チームにも Agentic Coding が浸透 - 生産性向上へ貢献 - AWS Community Meetups にて関連知見を発表 - Darmstadt - Bonn - 並列Claude Code運用経験が後の OSSプロジェクト - `Swarm Orchestrator` の設計思想へ直結