株式会社ずんだもん技術室AI放送局 podcast 20260917

youtube版(スライド付き) 関連リンク

• Claude Codeで開発期間を2.5か月から1か月に縮めた「ハーネス」の設計手法

本書は、SmartHRのプロダクトエンジニアがAIコーディングツール「Claude Code」を駆使し、新規機能の開発期間を当初の見積もりである2.5か月から1か月にまで短縮した実践的な設計手法「ハーネス」について解説したものです。AIを開発パートナーとして迎えるにあたり、手戻りを防ぎつつ成果を最大化するための具体的なアプローチが、新人エンジニアにも分かりやすく解説されています。

1. ハーネスが必要とされた背景

大規模な開発でAIエージェントをそのまま使い続けると、会話履歴の蓄積によって「コンテキスト（AIが一度に記憶・処理できる情報量）の枯渇」や「APIコストの急増」が発生します。また、既存システムへ悪影響（デグレ）を与えるリスクや、仕様の認識違いによる終盤での手戻りも大きな課題でした。これらを防ぐため、AIの作業環境をあらかじめ定義し、制御する仕組みとして「ハーネス（手順、状態JSON、完了判定スクリプトの3点セット）」が構築されました。

2. 協調動作を実現する4つの登場人物

ハーネス内では、役割を明確に分担させることでノイズとコンテキストの肥大化を防いでいます。

• オーケストレータ（メインセッション）: 進行役。フェーズの遷移や全体管理を行い、自身では実装コードを書きません。
• 実装エージェント: 細分化した1タスクごとに都度「新規セッション」として起動し、実装とコミットを行います。タスクごとにセッションをリセットすることで、過去の不要な履歴を引きずらず、常に高い精度を維持します。
• レビュアー: 「仕様突合」「並行性」「認可」「完結性」の4つの異なる観点を持つAI。タスクごとではなく、全タスク完了後に1回だけ並列起動させることで、無駄なトークン消費を抑えつつ、タスクをまたぐ欠陥を検出します。
• 機械検査（シェルスクリプト）: AIモデルを使わず、テストがgreen（成功）か、許可されたファイルパス以外の変更がないかなど、12項目を機械的に厳密に判定します。AIの自己申告に頼らない客観的なデグレ防止柵です。

3. 開発を成功に導く具体的な工夫

• テスト駆動開発（TDD）のルール化: 実装エージェントにはTDDを強制します。「テストを成功させる」という曖昧さのないゴールを提示することで、存在しない関数を作るなどのハルシネーション（AIの嘘）を即座にエラーで弾き、AI自身の自律的な修正を促します。
• 仕様（spec）と規律（rules）の分離: 作るべき機能を書いた「仕様ドキュメント」と、守るべき「規律（開発ルール）」を分けます。規律ファイルには適用範囲（パス）を指定することで、関係ないファイルを触るセッションには規律が読み込まれないようにし、コンテキスト量を節約します。
• 状態の外部化: 進行状況は軽量なJSONファイルに保存し、セッション切り替え時の引き継ぎに用います。確定した仕様はドキュメント側へ随時書き戻し、JSONファイルを肥大化させない工夫が施されています。

4. まとめ

AIエージェントを用いた開発において重要なのは、「AIモデルの優秀さ」に依存するのではなく、「AIが迷わず、安全に働ける周辺環境（ハーネス）をいかに設計するか」です。タスクを極小化し、セッションをクリーンに保ち、テストとスクリプトで品質を担保するこの手法は、これからのAI共同開発における強力な指針となります。

引用元: https://tech.smarthr.jp/entry/2026/09/16/110205

• 障害対応で Claude Code に調査を任せてみたら便利だった話

本書は、本番環境のデータベース（Aurora PostgreSQL）で発生した障害において、AIエージェントツール「Claude Code」を原因調査やインシデントレポート作成に導入し、対応を大幅に効率化した実体験を紹介する記事です。新人エンジニアにとっても、AIを「実務のアシスタント」としてインフラ運用にどう組み込むべきか、非常に学びの多い実践例となっています。

1. インシデントの状況

本番環境のDBで、writerインスタンスの内部プロセスが異常終了するインシデントが発生しました。自動フェイルオーバーでDB自体は即時復旧したものの、実行中だったバッチ処理が中断し、ロックを握ったままの状態になったため、手動での解除対応が必要になりました。

2. Claude Codeによる「超高速」な状況把握

通常、障害発生時はAWSの管理画面にログインし、手動でログやメトリクスを確認します。しかし今回は、Claude Codeに「再起動があったようなので状況を把握できますか」とだけ指示しました。具体的なクラスタ名や時刻を伝えなかったにもかかわらず、Claude Codeは自律的に以下のAWS CLIコマンドを組み合わせて調査を行いました。

• aws rds describe-db-clusters や describe-events （構成・履歴確認）
• aws cloudtrail lookup-events （人為的操作の有無の確認）
• aws cloudwatch get-metric-statistics （CPUや接続数の調査）

これにより、調査開始からわずか10〜15分で状況を把握し、Slackに共有できました。さらに、原因特定の決め手となる「FATAL: Aurora Runtime process unexpectedly exited」というエラーログも自動で見つけ出しました。

3. タイムラインとレポート作成の自動化

インシデント後に作成する「レポート」において、AWSのシステムログとSlack上の「人間の動き」を時系列に突き合わせる作業は時間と手間がかかります。 著者は、SlackのURLとレポート用テンプレートをClaude Codeに提示。Claude CodeはSlack MCP（外部ツール連携機能）経由でチャンネル履歴を取得し、AWSのイベント履歴と突き合わせて、秒単位の正確なタイムラインを自動生成しました。さらに、エラー内容を元にAWSドキュメントを検索し、「アプリの負荷ではなくAWS基盤側の問題である」という結論や、今後の監視改善の提案まで作成しました。

4. 安全面への配慮

AIにインフラ操作を任せるにあたり、誤操作を防ぐ権限管理が重要です。今回は「Read Only（参照専用）」のIAM権限を利用し、本番環境に破壊的変更が起きないよう安全性を担保しました。

5. まとめ

「情報の収集・整理はAIに任せ、判断や個別対応（アプリ側の影響特定、ロック解除、顧客連絡など）は人間が行う」という役割分担が極めて有効です。新人エンジニアの皆さんも、コマンドの検索やドキュメント作成をAIにサポートしてもらうことで、本質的な問題解決やシステム理解に集中し、より素早く成長できる環境を作ることができます。

引用元: https://developer.feedforce.jp/entry/2026/09/15/122838

• Claude Code Routinesを用いてIssueを自動で解消する仕組みを展開した話

本記事は、株式会社ラクスの若手バックエンドエンジニアが、AIコーディングアシスタント「Claude Code」を用いて、GitHub上の不具合や改善要望（Issue）の調査からプルリクエスト（PR）の作成までを半自動化する仕組みを構築し、チームへ導入した実践事例を紹介しています。

■ 構築した自動解消フローの全貌 定型的なタスクを自動実行できるClaude Codeの機能「Routines（ルーティン）」を活用し、以下のプロセスを構築しました。

1. 【コード調査】：人間が不具合のIssueを起票して調査依頼ラベルを貼ると、AIがコードベースを自動で調査します。AIは修正方針や実装にあたって確認したい事項をIssueのコメントに書き残します。
2. 【人間の確認（Human in the Loop）】：開発者がAIの提案をレビューし、方針が良ければGOサインを、修正が必要ならフィードバックを返信して、実装依頼ラベルを付与します。
3. 【実装とPR作成】：AIが回答を基にコードを修正し、自身のセルフレビューとテスト項目の作成を行います。その後、修正内容やテスト項目を記載したDraft PRを自動で作成します。
4. 【最終検証】：人間がローカル環境にブランチを取り込んで動作確認を行い、マージします。

■ この仕組みがもたらす5つのメリット

• 人間の時間外にAIを働かせる：夜間にAIが調査を進めておくことで、翌朝人間は回答するだけでよくなり、日中の並行作業を効率化できます。
• 履歴の可視化：Issue上に調査結果や修正方針の決定プロセスがすべて残るため、後からいつでも振り返ることができます。
• ローカル環境が汚れない：すべての処理はクラウド（サンドボックス）環境で行われるため、ローカルPCに不要な変更が入りません。
• 再現性のある挙動：個人のPC環境に依存せず、常に同じ実行環境で安定して動作します。
• 手戻りとコストの削減：実装前に「人間の確認」を挟むことで、AIが誤った方向に暴走するのを防ぎ、不要なAPI利用コストも抑えられます。

■ 直面した「AIネイティブ開発」の壁：レビュー負荷の増大 実際に運用してみて直面した最大の課題は、「人間によるコードレビューの負担が非常に重い」という点でした。 AIが書いたコードは、文法的に正しくテストも通ります。しかし、システム固有の複雑なビジネスルール（ドメイン知識）に本当に適合しているかを判断するには、結局人間が既存のコードベースを深く読み込み、AIの思考プロセスを逆算して紐解く必要がありました。その結果、コーディング時間が減った一方でレビュー時間が長くなり、効率化の恩恵が一部相殺されてしまうジレンマが生じました。