「ゆるテク なんかそれっぽい勉強会 2026.08」に登壇しました — Hermes Agent を活用した自律型開発
熊本で開催された「ゆるテク なんかそれっぽい勉強会 2026.08」に登壇しました。自分は「Hermes Agent を活用した自律型開発」というタイトルで、Issue を渡したら PR が返ってくるまでのループをどう設計するか、Skill として開発プロセスをコード化する狙い、そして自律性より止まり方が重要になる理由を話しました。あわせて、他の登壇者のお話への所感も残しておきます。
イベント概要
- 名称: ゆるテク なんかそれっぽい勉強会 2026.08
- 開催日: 2026 年 8 月 21 日（金）
- 開催場所: 熊本
- 普段はフルリモートワークなので、Human に残された数少ない仕事の一つ「現地登壇」として足を運びました
登壇内容「Hermes Agent を活用した自律型開発」
今回の話は「Issue を渡したら、PR が返ってくるまで」の 1 本の流れにまとめました。GitHub Issue から、調査・計画、実装・検証、レビュー、そして Human handoff までを 1 つのループにまとめて、コードを書かせるのではなく Issue を達成可能な状態まで進める、というのが今回のデモの狙いです。
flowchart LR
A[GitHub Issue] --> B[調査・計画]
B --> C[実装・検証]
C --> D[レビュー]
D --> E[Human handoff]
コード生成から、自律型開発へ
Chat-based な使い方と Autonomous な使い方の対比は、次の 4 つの軸で整理できます。
| 観点 | Chat-based | Autonomous |
|---|---|---|
| 次の一手を決めるのは | 人間 | エージェント |
| ワークフローの中心 | コード生成 | ゴール達成 |
| 検証の主体 | 人間が出力を確認 | ツールを使って自ら検証 |
| 状態が残る場所 | 会話の中 | Issue とリポジトリ |
会話の中に状態が積み上がる Chat-based では、会話が終わると状態も消えます。Autonomous 側では状態が Issue とリポジトリに残るため、翌日の別セッションでも続きを進められます。コードではなく状態遷移を任せる、という言い方をしました。
Hermes Agent は「実行環境」
Hermes Agent は LLM 単体ではなく、仕事を完了させるためのツールとコンテキストがまとまった実行環境として捉えると設計しやすいです。人間側は目標・制約・評価を渡し、Hermes Agent 側では Tools（ファイル・Git・ブラウザ）、Skills（手順を再利用する）、Memory（前提を引き継ぐ）、Delegation（実装と評価を分ける）を組み合わせて仕事を進めます。
Skill は「開発プロセスのコード」
Skill は長いプロンプトのテンプレートではなく、誰が何を担当するか、何を証拠に次へ進むか、どこで止まるかを再利用可能にした開発プロセスです。今回のデモでは oh-my-hermes から 3 つを紹介しました。
| フェーズ | Skill | 役割 |
|---|---|---|
| PLAN | omh-plan-issue | 要求を計画にし、codex・Claude Code の独立レビューを通して implementation-ready な Issue を作る |
| IMPLEMENT | omh-issue-loop | Issue URL を入口にして、実装・ローカル検証・複数レビュー・修正ループ・PR・CI 監視・Human handoff までを進める。マージはせず、最終判断は人間へ戻す |
| REVIEW | omh-pr-multi-review | Claude Code の 3 種類のレビューと codex レビューを独立して実行・集約する。レビューの一部が失敗しても、その失敗を隠さずレポートに残す |
プロンプトではなく、再現可能な手順と停止条件を共有する、というのが Skill の位置付けです。
自律性よりも、止まり方が重要
安心して任せるためには、成功条件だけでなく停止条件を明示的に組み込む必要があります。スライドでは次の 6 つを挙げました。
- テスト失敗を成功と報告しない
- 実行できない検証は未確認にする
- レビューを対象の差分に紐づける
- 権限・時間・修正回数に上限を置く
- 技術的ブロッカーを明示する
- 根拠が不足したら人間へ戻す
自律的に走り続けることではなく、根拠がなくなった瞬間に自律的に止まれることが、任せられる度合いを決めるという主張です。
実務で効いた 3 つの設計
日々のプロジェクトで効いた設計を 3 つに絞ってまとめました。
- ゴールを機械的に判定する: テスト・型検査・Lint・ビルド・受け入れ条件・実ブラウザ検証など、二値で判定できる評価関数へ落とし込む
- コンテキストを会話の外へ出す: Issue・AGENTS.md・ドキュメント・Skills・テスト・PR チェックリストなど、会話が消えても残る場所に置く
- 実装と評価を分離する: 実装・コードレビュー・セキュリティレビュー・CI・Human approval を別のロールとして走らせる
組織には、段階的に入れる
権限もいきなり広げず、段階的に入れる方が安全です。検証可能性に合わせて、次のような順番で権限を広げていくのが実践的でした。
flowchart LR
S1["1<br>調査・説明"] --> S2["2<br>ローカル実装"]
S2 --> S3["3<br>テスト・レビュー"]
S3 --> S4["4<br>PR・CI 確認"]
S4 --> S5["5<br>デプロイ・本番検証"]
小さく評価しやすい Issue から始めるのがコツです。
まとめ
まとめは 3 点にしました。
- 自律型開発は、コード生成ではなく開発ループの自動化である
- 人間の役割は、目標・制約・評価関数を設計すること
- 安心して任せるには、成功条件だけでなく停止条件が重要
キャッチとしては「人間はゴールを、AI はループを」というフレーズで締めました。
他の登壇の所感
「ハーネスとループのエンジニアリング」 高手智基さん
自分の登壇テーマと単語の重なりが多く、勝手にシンパシーを感じながら聞いていた発表です。ハーネスとループの発想はコード生成の話にとどまらず、動画生成側にも綺麗にはまるという内容で、印象に残っています。
AI動画の進化すごすぎ
— 智基/Tomoki (@tomolld) August 10, 2026
芥川龍之介の蜘蛛の糸作ってもらったんだけど、セリフとかも自然で凄い pic.twitter.com/vpNkJHWrzz
トークン費用 1 万円ぐらいでこの動画を作れるらしく、動画生成においてもハーネスを設計して、シナリオを書けばちゃんとした動画が返ってくる、という状況に来ているのがすごいなと思いました。コード生成で「プロンプトではなく再現可能な手順」に寄せているのと同じ話が、モーダルを跨いで成立しているのを見せてもらった感覚です。
「AI 時代に失われていくロストテクノロジ Vol1、RDB の Index」 おーのりょうさん
よく使われるけれど適当に使ってしまうことも多い RDB の Index について雑に話す、という趣旨の LT でした。
B-Tree の内部構造や、複合インデックスの列順、選択性の考え方など、大学の講義を思い出す構成で、AI が代わりにクエリを書いてくれるとしても、そのクエリがどれだけの物理 I/O を発生させるのかを読める人間側の知識は残しておきたいと素直に感じました。「AI 時代に失われていく」というシリーズタイトルもうまく、続編を楽しみにしています。
以上、「ゆるテク なんかそれっぽい勉強会 2026.08」に登壇し、Hermes Agent を活用した自律型開発の話と他登壇者への所感をまとめた、現場からお送りしました。