指示待ちから変化に応じて動く Claude Codeへ 環境からAgentへの帰り道を作る Gota (@gota_bara) 2026-08-28 Claude Code Meetup Japan #7 

自己紹介 Gota (@gota_bara) ふだん やってること プロダクトエンジニア / アナリティクスエンジニア Sandboxを持つCloud Agentのプロダクト開発 / 意思決定のためのデータ整備 (dbt) OSS cc-sdd(★3.6k) / skillport(★400) 今⽇ まどマギ新作の公開⽇ですが登壇に来ました。もちろん映画は既に⾒ました 2 

Playable Arena さっき公開した！ / arena.gotalab.dev 遊べるベンチマーク！ 3 

Claude Code x Opus 5はテイストが良いが遅い&高い！ Claude Code/ Codex/Cursor/Pi/OpenCodeの 5つのハーネス x 恣意的なモデル でAgent Evalsも回してる 4 

増える並列と待ち作業 同時にいくつもの作業が動く。そしてCI待ち、レビュー待ち、完了待ちも⼀緒に増えてい く 5 

人が担う中継 どれが終わった？ どれが失敗した？ 次は何をする？ 結果をコピーし、宛先を判断して、 該当するsessionへ貼り直す 6 

並列の数は増やせても、⼈が⼀度に⾒ られる量には、どうしても限界がある 7 

結果の帰り道 環境とは、file、build、CI、レビュー、外部service、時間。失敗やレビュー指摘の帰り 道は⼈を経由している。ここは環境から直接返せる 8 

CI失敗が作業を呼び戻す Auto-fix CI失敗やreview commentが、PRの作業を呼び戻した 9 

完了の知らせが届く completion notification ‧ 2026年7⽉追加 バックグラウンドのAgentが終わった時、待っているsessionへ完了の知らせが届いた 使⽤上限で⽌まった仕事も、解除されたら勝⼿に再開する(usage-limit auto-continue ‧ 2026年8⽉追加) 10 

Claude Codeは、変化を受け取って 仕事を再開できる 11 

資料作成のpluginsの場合 議事録や要約レポートなど、読む負担を下げて認識合わせと意思決定を速くする資料づく りを、briefing pluginに束ねてClaude Codeで運⽤している 3つの出⼒：HTML、PowerPoint、Docx、Google Slidesを同じ流れで作る 検査を同梱：書き⽅ルール、Writing Style LSP、Hooks(⼀貫性check) この資料も：今⽇の登壇資料もこのpluginで8割作った 12 

資料作成の流れ 表記のミス、buildの失敗、公開後の変化の3箇所で、⼈が結果を⾒て再指⽰していた 13 

レビューまで残るミス ● ● この1枚に、直すべき箇所が ある 表記ゆれ、リンク切れ、壊 れた図、絶対pathなど 14 

レビューまで残るミス 1) 禁⽌記号のem dash 2) AI特有の語彙 3〜6) 表記ゆれ(OpenAI、 Anthropic、Claude Code、 GitHub) 7) 壊れた図 8) ⾶べないリンク 9) 環境依存の絶対path 10) ⾰新的な... 何も⾔ってない⽂ 体 15 

Writing Style LSPを作った LSP(Language Server Protocol)はエディタの診断を⽀えてきた標準の仕組み。 Claude Code pluginではLSPを利⽤可能 表記と語彙の検査：表記ゆれ、禁⽌記号、AI特有の語彙を編集した瞬間に指摘 参照の検査：リンク切れ、無いアンカー、壊れた画像、絶対pathを検出 MarkdownもHTMLも：対象はcodeに限らない。YAMLもJSONも同じ形で検査 ⾃作もできる：ルールはJSONで定義してpluginとして接続。難しくない 16 

指摘ゼロになった資料 ● ● ● ● 9件の指摘が0件になった ⽂体もよくなった！ 図も参照も⽣きた状態で、 ⼈のレビューへ渡せる ⼈のレビューは、内容の判 断に集中できる 17 

Hooksでも大体できる 今のLSPの帰り道は、Hooksでも⼤体作れる。機械で決められることは外で処理し、判断 が要る時だけAgentへ返す 18 

推論の外で変わる環境 Claudeが⼿を⽌めている間も、レビューの返事や共同編集や外部serviceは動いている 19 

Monitorの仕組み 常駐する処理が、状態の変化を起動中のClaude Codeへ返す。この資料では、deck検証が 失敗へ変わった時だけreportの場所が届き、直せば復旧も届く 20 

資料作成のloopが閉じた 編集した瞬間、実⾏の直後、公開後の変化を次の⾏動へつないだ。レビューはsubagent へ委任し、指摘と修正のloopをAgent同⼠で回す 21 

PowerPointのみの図形で短いプロンプトから一発生成の例 22 

同じ帰り道は、コードとチームの ⽇常にも作れる 23 

落ちた時は待つ Monitor GitHubが落ちてpushが失敗。Monitorは復旧した時だけ知らせ、remoteの状態を確かめ てから再開する（というか落ちすぎ） 24 

長い実行を見張らせる Monitor Agent評価の計測jobは約5時間。Monitorに⾒張らせておけば、Claudeが呼ばれるのは節 ⽬と異常の時だけ 25 

Agent同士で知らせ合う Cross-session messaging ‧ 2026年8⽉追加 別のAgentが完了した時、Cross-session messagingで取りまとめ役のsessionへ知らせ が届く。 notify_when_idle: true で「idle になったら1回通知」が可能 26 

Routinesで新しく始める Routines 決まった時間やGitHubの変化が、新しいsessionを起こす。起動、成果、次の変化で、⼀ 回り⼤きいloopが閉じる 27 

失敗を仕組みへ昇格する 帰り道を増やして、効かないものは削る、いちばん外側のloop。採⽤も削除も⼈が決める 1 2 3 4 毎週集める 仕分ける 昇格と削除 翌週は⾃動 1週間の失敗patternを集 計する 機械で判定できる失敗 と、鳴らなくなった検査を 選び出す LSP、Hooks、テストへ昇 格し、効かない帰り道は 削る。決めるのは⼈ 同じ失敗は編集した瞬間 に⾒つかる 28 

編集直後の確認から毎週の仕事まで、 ⾃動で次へ進められる 29 

全部 /loopでいいのでは どの帰り道も、/loopの定期確認で⼤体回せる。 知らせる⽅法がない場所では、/loopが保険になる 30 

変化がなくても費用はかかる Fableで5分おきに約1時間20分、17回でおよそ5.25ドル(実測)。ほぼ全部が「変化なし」 の確認で、この調⼦で24時間ならおよそ90ドル。会話にも空振りの報告が積もる 2ドル 7.25ドル 31 

通知も増やしすぎない 通知も増やしすぎない。成功や「変化なし」の時は知らせず、同じ知らせは⼀度だけ。載 せるのは三つ 何が変わったか：状態の遷移だけを短く伝える どれほど重要か：今の仕事を⽌めてまで⾒るべきかが分かる 詳しい結果の場所：全⽂を流さず、レポートへのリンクや判断できる最低限を渡す 32 

帰り道の全体マップ ⼈が指⽰して回収する⼀⽅向をやめ、変化が起きる場所ごとに検知と返し先を決める。判 定できるものは全部環境に含める 33 

人が決めるのは三つだけ 環境から結果が返るようになればloopは閉じ、⼈の認知負荷は下がる 1 何が起きたら動く？ 編集、テスト失敗、CI失敗、レビュー完了、利⽤上限の解除、毎週⽉曜 2 何が成功で、何が失敗？ diagnostic 0、テスト成功、remoteへ反映済み。確かめて判定する 3 結果を受けて、次に何をする？ 失敗は修正へ戻す。同じ失敗が3回続いたら⼈へ返す。成功したら⽌める 34 

ありがとうございました Gota (@gota_bara) 感想‧質問は X @gota_bara まで 35 

Appendix 今回紹介した機能一覧 loopを閉じる仕組みは、標準でここまで揃っている。何の変化を捉えると、何ができるか 何が起きたら 機能 できること 編集した瞬間 LSP 表記‧参照のミスをその場で返す tool‧コマンドの直後 Hooks 機械で確かめ、失敗した時だけ呼び戻す 外部の状態が変わった Monitor 変化を起動中のsessionへ知らせる CI失敗‧レビュー指摘 Auto-fix 同じPRの作業を再開する 別のAgentが完了した Messaging 待っているsessionへ知らせる 利⽤上限が解除された auto-continue 同じ作業を⾃動で再開する 時間‧GitHubの変化 Routines 新しいsessionを起動する 知らせが無い場所 /loop 定期的に⾒に⾏く(保険) 36