20260623_Loop Engineeringで自分の分身の問い合わせBotを作る

https://meguro-lt.connpass.com/event/390951
の登壇資料

Transcript

1. Loop Engineeringで自分の分身の問い合わ せBotを作る 2026-06-23 めぐろLT #37「AI×チーム開発、みんなどうしてる？」 @ryugen
2. 5分で 最近社内でやっている取り組みの話をします
3. whoami 山本竜玄 Yamamoto Tatsunori (@ryugen04) 経歴: 株式会社ヘンリーで医療・ヘルスケア領域の Webエンジニア(ロールはEpic Owner)やってい ます。 趣味・領域 : Neovim好きです/スクラム好きです アクアリウム/カポエイラ/薬剤師 その他: ビールが好きです！めぐろLTは来るのも初
4. 突然ですが皆さん、 問い合わせ対応 はどうしていますか？
5. 私の社内での流れ 機能開発 開発チームがEpicという単位で新規プロジェクトの開発・テストを 行う 問い合わせ それと並行して、顧客からの問い合わせの調査・不具合修正を エンジニアが行う 問い合わせがスプリントのブロッカー になりやすい
6. 問い合わせの属人化 医療ドメインの開発特性によって、以下のことが起こりやすい - 仕様が外的な側面で決まる、超複雑(厚労省のテキストドキュメン トなど) - 外的なマスタに依存もしている - 実装にも歴史があり、実装経緯・ドメインの詳細まで把握できてい るエンジニアが少ない - Epic Ownerとしては、スプリント外の作業をできるだけ隔離したい 結果、自分に問い合わせタスクが集中する(させている)
7. 本業ではないので本腰は入れたくない でもドメインの複雑性に依存した トイルを解消し たい
8. 自分のSlack Botを作って育てている
9. やっていること Claude Code Channel で(※個人用途で)bot 運用 改善ループを回るよう にしている
10. 失敗談 • 最初はそもそも、Claudeのremote sessionでの回答でなんとかし たいと思っていた ◦ 開発リポジトリにスキルをおいてslack mentionしてみたが、ス キル発動率も低い ◦ 他の開発のruleやskillsが混じってしまい、速度・精度ともに低 かった ◦ 回答先も担当領域Eng以外がメインだが実装の狭い話をしが ち • Claude Code Channelで0->1で構築してみたが、品質が低かった り逐次リポジトリ上で改善するのに限界があった ◦ Loop Engineeringをやりたくなった
11. Claude Code Channelとは？ • Claude Code の interactive session に、外部シス テムからメッセージを流し込む仕組み • Slack などの外部イベントを、Claude Code 側では <channel ...>...</channel> 形式の入力として受け 取る • 一回きりの claude -p 実行ではなく、常駐セッショ ンとして使う • MCP server が notifications/claude/channel を 送ることで、Claude Code に通知する • Claude Code は受け取った channel message を 読んで、MCP tools を呼び出す • 今回の利用用途では、 Slack と Claude Code をつ なぐブリッジとして使っている https://code.claude.com/docs/en/ch annels
12. なぜClaude Code Channelか？ Pros - 共通リポジトリにならず、自分用のbotリポジトリとして運用できる - work状況がターミナルで追える - 質問への回答は、既存のコード実装などとコンテキストやステップ が違うのでリポジトリをわけれる - そもそもの回答の自動化の実現性もわからない状態で、予算や アーキテクチャを追加せずに運用できる Cons - 自分のPCの起動状態に依存する - 知見については、チームにフィードバックしないと結局属人化する
13. やっていること Claude Code Channel でのやり取りの際に、 issueを外部保存させる 別のCodex sessionで /goalで修正ループを 回させている
14. Loop Engineeringとは？ • →の記事が良かったので引用して紹介 • AI agent に毎回人間が prompt を投げるのではな く、agent に prompt を投げる「仕組み」を設計する 考え方 • 1回限りの prompt ではなく、目的・状態・検証・次 の行動を持つ反復システムとして agent を動かす • 人間の役割は「次に何を頼むか」を毎回考えること から、「どんなループで仕事を回すか」を設計するこ とへ移る • coding agent を単体の道具として扱うのではなく、 発見・実行・検証・記録を含む小さな業務システムと して扱う https://addyosmani.com/blog/loop-e ngineering/
15. Loopに必要な要素 Automation: 定期的に作業を発見・triage する仕組み Worktrees: 複数 agent が並行作業してもファイル衝突しない隔離環 境 Skills: project knowledge や作業手順を外部化した再利用可能な 知識 Plugins / Connectors: issue tracker、Slack、DB、CI など実際の ツールにつなぐ仕組み Sub-agents: 実装者と検証者を分けるための複数 agent 構成 State / Memory: 何をやったか、何が残っているかを会話外に保存 する場所
16. Stateへの保存内容 →みたいな形でissueを保存させ るようにしている。 (非同期のサブエージェントでの 修正フローなどもやってみたが、 改善精度としていまいちだった)
17. 実際のイメージ →みたいな形でSlack起点でやり取 り、改善要素などもSlackのチャット で伝えている
18. まとめ - やっていることはシンプルで、個人用途で、属人化した自分のドメイ ン知識や調査フローをClaude Code Channel, Loop Engineeringで 徐々に定式化できるようにしている - 繰り返しているうちに問い合わせに利用可能な品質になってきてい る - 複雑すぎるドメインや、コードベースなどについてはdocsなどに大量 にドキュメント化してコミットして記載しても、そのまま(特にEng以外 の)問い合わせに利用することは難しかった - よりよい仕組みとしては、Claude Managed AgentsやRAGの整備を するなどもあるが、実用性もわからないうちから主タスクでないことに 取り組むにはコストが大きい - 特に組織全体へ展開する前に、MVPとして知識の蒸留・回答フロー の確立として徐々に取り組むにはよい感じだった
19. ご静聴ありがとうございました