AIを賢くしたいなら、まずは人間の改善ループから

サポーターズCoLab・ハーネスエンジニアリング事例共有LT会のLT資料です。
https://supporterz-seminar.connpass.com/event/391344/

1. AIを賢くしたいなら まずは人間の改善ループから 2026/05/12 ハーネスエンジニアリング事例共有LT会 株式会社TOKIUM Webエンジニア 坂上 晴信
2. 坂上 晴信 Harunobu Sakaue 経歴 1995年生まれ。東京の離島・伊豆大島出身。 エンジニア → DevHR（= 開発組織専任の人事）→ エンジニア 2016年 3月 東京高専 情報工学科卒 2016年 4月 株式会社TOKIUM 入社 Android/Webエンジニア 2023年 1月 DevHRにロールチェンジ 育成・組織づくり・採用広報 2025年12月 再びエンジニアにロールチェンジ Webエンジニア NOW! 自己紹介 / リアルのすがた ⚫︎ ⚫︎ ⚫︎ ⚫︎ ⚫︎ 2
3. にしこりさぶろ〜 @subroh_0508 好きなもの Kotlin / アイドルマスター / ラブライブ！ Kotlin本体へのContribute経験、Kotlin Festへの複数回の 登壇経験アリ。DevHR時代も趣味でKotlinを書き続け、 "200名収容の会場で技術登壇をした人事"になった。 プライベートでは、アイマスPとライブライバーを兼任。 『シャニマス』三峰結華と『蓮ノ空』村野さやかが 人生のロールモデル。 自己紹介 / インターネットのすがた 3
4. ハーネスエンジニアリング めちゃめちゃ盛り上がってる！ 4
5. 他社のハーネスがどうなってるか 見て学びたい！ 5
6. 実際に運用中のハーネスの紹介 ハーネス構築におけるTipsの紹介 おしながき 6
7. 新規PJで実際に運用している（広義の）ハーネスを 2つ 紹介 1. チケットから実装・Pull Request作成まで自動化 jita-to-pr 2. コードレビューの自動化 self-review … AI生成コードの品質磨き込み code-review … マージ前ガード + 変更意図のチーム共有知化 実践事例 7
8. jira-to-pr スキル jira-to-pr TICKET-XXX で実行、以下4ステップを一気通貫で通す 1. タスクの目的・完了条件が記載されたJiraチケットから、実装計画を立案 2. 計画をGitHub Issueに蓄積、修正点がないか開発者に確認 3. GitHub Issueを参照して、クラウド上 or ローカル上で実装 4. Pull Requestをdraftで作成 3人で週30PR、溺れかけた開発チームがClaude Codeスキルでレビューを回した話 | TOKIUMプロダクトチーム テックブログ zenn.dev/tokium_dev/articles/pr-review-workflow-with-claude-code-skills 事例 1: チケットからPull Request作成まで自動化 1つのJIRAチケットから複数のPRが出てくることも珍しくなく、週30 PR （※注: 3名のチーム） の土台はこのスキルです。 “ 8
9. スタートは、Pull Request作成時に自動実行される「Codexによる自動レビューアクション」 当初、人間が見落としてしまう観点をカバーしてもらうために導入したところ… → 運用してみると 「同じ AI レビューでも、目的によって設計が変わる」 ことに気付き、 1ヶ月ほどで 2系統に分岐 していった。 系統 対象 目的 self-review 自分のPull Request (AI生成コード) AI生成コードの 品質磨き込み code-review 他メンバーのPull Request マージガード + 変更意図の共有知化 事例 2: コードレビューの自動化 9
10. AI生成コードの品質を、AI自身のループで磨き込む 役割 自分のPull Requestに対し レビュー → 修正 を 指摘収束まで反復 動き Agent Teamsで複数観点からレビュー 結果をマージし、重要度を3段階に分類 指摘をPull Requestに投稿 → 修正まで実行 ねらい AIの生成物の品質を 人間のレビュー前に磨く 事例 2-A: self-review 10
11. マージ前の品質検証 + Pull Requestの意図をチーム全体に共有 役割 他メンバーのPull Requestに対し マージ前のガード + 意図の整理・構造化 動き Jira/Slack/レビュー指摘から 意図 を収集 Google's Code Review Guidelineに沿って マージのブロッカーを洗い出し、修正提案 ねらい マージを意識した修正提案 + 意図の共有 事例 2-B: code-review 11
12. なんかすごそう！ 自分のチームでもやってみたい！ 12
13. でもどこから始めればいいか 分からない 13
14. 失敗しても良いところから入れる AIの思考過程を記録し、観察する 課題点をこまめに修正する スムーズなハーネス構築を実現する3つのTips 14
15. 未知の技術、かつ成果物に揺らぎが生まれるAIだからこそ、 失敗時のコストが少ない箇所から 組み込むことが重要！ jira-to-pr : 最終成果物はDraftのPull Request作成、人間の最終承認 を経てマージ しっくりこなかったら closeすればOK code-review : Pull Requestのopen時に Codex で走らせ、簡単なプロンプトで指摘 的外れなコメントは 無視すればOK / 動かなければ 削除（レビューが人間に戻るだけ） そもそも Linterや単体テスト等の（AIよりも）枯れた技術 で品質向上ができるなら、 最優先で組み込む Tips 1: 失敗しても良いところから入れる 15
16. 開発者の思惑からズレた挙動 / 効率の悪い挙動を察知できる状態を整える 残すもの 生成物 スキル実行の 過程 実装計画・進捗管理 → Issue / Pull Request の descriptionやcomment AIの思考過程 → ローカル（ tmp ディレクトリ等） 集計・分析の 基盤 分析レポート → レポジトリに蓄積 ※AIの自動レビュー結果から 指摘再発率 / 修正サイクル数 / カテゴリ集中度 等 を計測し、ハーネスの改善に還元 Tips 2: AIの思考過程を記録し、観察する スキル定義の改善につながるものは レポジトリ外に、 プロジェクトコードの改善につながるものは レポジトリ内に蓄積！ 16
17. レトロスペクティブで「よりよいプロセス」を議論する時間を確保 週1回、ハーネスも含めたプロセス改善が必ず実行される状態になっている 細かな改善アイディアは積極的に取り入れる 不満点があれば、雑にSlackで共有 → スキル化して解決 メンバーのアクションにはポジティブに反応し、前向きに議論を交わす Tips 3: 課題点をこまめに修正する 17
18. 「AIが賢く振る舞わざるを得ない環境」を作るのが ハーネスエンジニアリング、これをスムーズに組み込むには… 導入 → 観察 → 改善のサイクルを失敗してもいい領域から組み込み、 短いスパンで回す AIで改善ループを構築する前に人間による改善ループを構築し、 業務プロセスを継続的にアップデートする ことが重要 まとめ 18
19. AIハーネスを試す対象を「失敗してもよい領域」から選ぶ AIのアウトプットは過程も含めて、ローカルのMarkdown / Issue / Pull Requestのコメントなど、形式問わず積極的に残す 明日からできること 今アツいハーネスエンジニアリング、 ベストプラクティスが確立されていないからこその楽しさがたくさん！ みなさんも明日から、チャレンジしてみてね 19
20. 資料公開＆技術発信は公式Xから 本日のスライドは公式Xで公開！ 開発チームの技術やイベント情報を 発信中、フォローお願いします！ @TOKIUM_Dev 情報発信中！ 20