https://hdknr.github.io/blogs/tags/%E9%96%8B%E7%99%BA%E3%83%97%E3%83%AD%E3%82%BB%E3%82%B9/Recent content in 開発プロセス on hdknr blogHugo -- 0.157.0jaThu, 23 Apr 2026 00:00:00 +0000https://hdknr.github.io/blogs/posts/2026/04/%E3%83%8F%E3%83%BC%E3%83%8D%E3%82%B9%E3%82%A8%E3%83%B3%E3%82%B8%E3%83%8B%E3%82%A2%E3%83%AA%E3%83%B3%E3%82%B0%E3%81%A8%E3%81%AE%E5%90%91%E3%81%8D%E5%90%88%E3%81%84%E6%96%B9-%E3%83%AB%E3%83%BC%E3%83%AB%E3%83%95%E3%82%A1%E3%82%A4%E3%83%AB%E3%82%92%E8%B6%85%E3%81%88%E3%81%A6%E9%96%8B%E7%99%BA%E3%83%97%E3%83%AD%E3%82%BB%E3%82%B9%E3%82%92%E8%A8%AD%E8%A8%88%E3%81%99%E3%82%8B/Thu, 23 Apr 2026 00:00:00 +0000https://hdknr.github.io/blogs/posts/2026/04/%E3%83%8F%E3%83%BC%E3%83%8D%E3%82%B9%E3%82%A8%E3%83%B3%E3%82%B8%E3%83%8B%E3%82%A2%E3%83%AA%E3%83%B3%E3%82%B0%E3%81%A8%E3%81%AE%E5%90%91%E3%81%8D%E5%90%88%E3%81%84%E6%96%B9-%E3%83%AB%E3%83%BC%E3%83%AB%E3%83%95%E3%82%A1%E3%82%A4%E3%83%AB%E3%82%92%E8%B6%85%E3%81%88%E3%81%A6%E9%96%8B%E7%99%BA%E3%83%97%E3%83%AD%E3%82%BB%E3%82%B9%E3%82%92%E8%A8%AD%E8%A8%88%E3%81%99%E3%82%8B/<p>2026 年 4 月、Findy が主催したオンラインイベント「<strong>Harness Engineering 入門 〜 AI エージェントを制御するアプローチ〜</strong>」が開催された。r.kagaya 氏の登壇「エージェントの開発環境を内製して気づいた『これもハーネス』」は参加者から「レベル高すぎた」と評されるほど反響を呼んだ。本記事では、r.kagaya 氏が公開した SpeakerDeck 資料「ハーネスエンジニアリングにどう向き合うか 〜ルールファイルを超えて開発プロセスを設計する〜」をもとに、ルールファイルを超えたハーネスエンジニアリングの考え方を整理する。</p> <h2 id="イベント概要">イベント概要</h2> <p><strong>【Harness Engineering 入門】AIエージェントを制御するアプローチ</strong>（<a href="https://findy.connpass.com/event/388471/">connpass #388471</a>）は、AI エージェントによる開発が広まる中でハーネス設計がどのような意味を持つかを掘り下げるイベント。対象は AI エージェントを積極的に使っているエンジニア、チーム開発に AI を取り込もうとしているエンジニア層だ。</p> <p>複数の登壇の中で r.kagaya 氏のセッションは、自社でエージェントの開発環境を内製する過程で見えてきた「これもハーネスだ」という気づきを軸に、ルールファイル設定で終わらないハーネスエンジニアリングの本質を語った。</p> <h2 id="ルールファイルから始まるハーネスエンジニアリング">ルールファイルから始まるハーネスエンジニアリング</h2> <p>多くのエンジニアがハーネスエンジニアリングを始める入り口は <strong>CLAUDE.md などのルールファイル</strong> だ。「こういうコードを書いてほしい」「このコマンドは使わないで」といった制約を自然言語で記述し、AI の振る舞いをコントロールする。</p> <div class="highlight"><div style="color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;-webkit-text-size-adjust:none;"> <table style="border-spacing:0;padding:0;margin:0;border:0;"><tr><td style="vertical-align:top;padding:0;margin:0;border:0;"> <pre tabindex="0" style="color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;-webkit-text-size-adjust:none;"><code><span style="white-space:pre;-webkit-user-select:none;user-select:none;margin-right:0.4em;padding:0 0.4em 0 0.4em;color:#7f7f7f">1 </span><span style="white-space:pre;-webkit-user-select:none;user-select:none;margin-right:0.4em;padding:0 0.4em 0 0.4em;color:#7f7f7f">2 </span><span style="white-space:pre;-webkit-user-select:none;user-select:none;margin-right:0.4em;padding:0 0.4em 0 0.4em;color:#7f7f7f">3 </span><span style="white-space:pre;-webkit-user-select:none;user-select:none;margin-right:0.4em;padding:0 0.4em 0 0.4em;color:#7f7f7f">4 </span></code></pre></td> <td style="vertical-align:top;padding:0;margin:0;border:0;;width:100%"> <pre tabindex="0" style="color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;-webkit-text-size-adjust:none;"><code class="language-markdown" data-lang="markdown"><span style="display:flex;"><span># CLAUDE.md の例 </span></span><span style="display:flex;"><span><span style="color:#75715e">## Bash コマンドの必須ルール </span></span></span><span style="display:flex;"><span><span style="color:#66d9ef">-</span> <span style="color:#e6db74">`&amp;&amp;`</span> でコマンドを繋がない </span></span><span style="display:flex;"><span><span style="color:#66d9ef">-</span> <span style="color:#e6db74">`/tmp`</span> を使わない（<span style="color:#e6db74">`.claude/temp/`</span> を使う） </span></span></code></pre></td></tr></table> </div> </div><p>この段階では「うまく動くルールを育てる」フェーズであり、試行錯誤でルールを追加・削除していく。しかし、ここで止まってしまうと <strong>本当の意味でのハーネスエンジニアリング</strong> には到達できない。</p> <h2 id="ルールファイルの限界">ルールファイルの限界</h2> <p>ルールファイルだけに依存したアプローチには構造的な限界がある。</p> <table> <thead> <tr> <th>課題</th> <th>内容</th> </tr> </thead> <tbody> <tr> <td><strong>変更の影響が不透明</strong></td> <td>あるルールを変えたとき、どの程度・どの方向に結果が変わるか測定できない</td> </tr> <tr> <td><strong>劣化の検知が困難</strong></td> <td>モデルのアップデートや使い方の変化でルールの有効性が静かに落ちる</td> </tr> <tr> <td><strong>再現性の欠如</strong></td> <td>同じルールで試しても毎回違う結果が出る場合の原因特定が難しい</td> </tr> <tr> <td><strong>スケールしない</strong></td> <td>チームが大きくなるほど「誰がどのルールを管理しているか」が曖昧になる</td> </tr> </tbody> </table> <h2 id="ルールファイルを超えた視点開発プロセスとして設計する">ルールファイルを超えた視点：開発プロセスとして設計する</h2> <p>r.kagaya 氏が提示したのは、ハーネスエンジニアリングを「ルールを書く行為」ではなく <strong>「開発プロセスを設計する行為」</strong> として捉え直す考え方だ。</p>