<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
    <channel>
        <title>ソフトウェア工学 on KnightLiブログ</title>
        <link>https://www.knightli.com/ja/tags/%E3%82%BD%E3%83%95%E3%83%88%E3%82%A6%E3%82%A7%E3%82%A2%E5%B7%A5%E5%AD%A6/</link>
        <description>Recent content in ソフトウェア工学 on KnightLiブログ</description>
        <generator>Hugo -- gohugo.io</generator>
        <language>ja</language>
        <lastBuildDate>Fri, 15 May 2026 08:46:23 +0800</lastBuildDate><atom:link href="https://www.knightli.com/ja/tags/%E3%82%BD%E3%83%95%E3%83%88%E3%82%A6%E3%82%A7%E3%82%A2%E5%B7%A5%E5%AD%A6/index.xml" rel="self" type="application/rss+xml" /><item>
        <title>Vibe Coding を拒む：Matt Pocock の skills リポジトリが AI コーディングに工学的制約を足す</title>
        <link>https://www.knightli.com/ja/2026/05/15/matt-pocock-skills-ai-engineering-workflow/</link>
        <pubDate>Fri, 15 May 2026 08:46:23 +0800</pubDate>
        
        <guid>https://www.knightli.com/ja/2026/05/15/matt-pocock-skills-ai-engineering-workflow/</guid>
        <description>&lt;p&gt;AI がコードを書く速度が上がるほど、プロジェクトが崩れる速度も上がり得る。問題はモデルが関数を生成できるかではなく、要件を理解し、チームの言葉に従い、既存アーキテクチャの中で小さく進められるかだ。&lt;/p&gt;
&lt;p&gt;Matt Pocock が公開した &lt;code&gt;mattpocock/skills&lt;/code&gt; は、vibe coding とは逆の方向を示している。AI に開発プロセス全体を任せるのではなく、成熟したソフトウェア工学の制約の中に置く。&lt;/p&gt;
&lt;p&gt;プロジェクト：&lt;a class=&#34;link&#34; href=&#34;https://github.com/mattpocock/skills&#34;  target=&#34;_blank&#34; rel=&#34;noopener&#34;
    &gt;https://github.com/mattpocock/skills&lt;/a&gt;&lt;/p&gt;
&lt;p&gt;これは魔法の prompt ではない。要件確認、ドメインモデリング、TDD、診断、アーキテクチャレビューを、AI agent が使いやすい workflow にした skills の集合だ。&lt;/p&gt;
&lt;h2 id=&#34;まずアラインメント失敗を防ぐ&#34;&gt;まずアラインメント失敗を防ぐ
&lt;/h2&gt;&lt;p&gt;AI コーディングで最も多い失敗は、モデルが理解したと思ったら、実は曖昧な説明から推測していただけ、というものだ。&lt;/p&gt;
&lt;p&gt;&lt;code&gt;grill-me&lt;/code&gt; はこれを反転させる。コードを書く前に、AI を厳しいレビュアーにし、分岐、境界、未決事項を質問させる。&lt;/p&gt;
&lt;p&gt;たとえば「ログインページを作って」と頼んだら、先に聞くべきことは次のようなものだ。&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;パスワード忘れはどう扱うか&lt;/li&gt;
&lt;li&gt;外部ログインをサポートするか&lt;/li&gt;
&lt;li&gt;ログイン失敗時のエラー表示はどうするか&lt;/li&gt;
&lt;li&gt;アカウントロック、CAPTCHA、リスク制御は範囲内か&lt;/li&gt;
&lt;li&gt;成功後はどこへ遷移するか&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;この段階は遅く見えるが、後の手戻りを減らす。コード生成が安くなるほど、曖昧な要件のコストは大きくなる。&lt;/p&gt;
&lt;h2 id=&#34;ドメイン言語をコンテキストに入れる&#34;&gt;ドメイン言語をコンテキストに入れる
&lt;/h2&gt;&lt;p&gt;次の問題は汎用語彙だ。モデルはチーム内の業務用語を知らないため、変数名、関数名、ドキュメントの言葉がずれていく。&lt;/p&gt;
&lt;p&gt;&lt;code&gt;grill-with-docs&lt;/code&gt; は質問しながら、&lt;code&gt;CONTEXT.md&lt;/code&gt;、ADR、ドメイン文書を確認する。確認済みの用語、境界、判断は、再利用できるコンテキストとして残せる。&lt;/p&gt;
&lt;p&gt;これはドメイン駆動設計のユビキタス言語に近い。チームが user ではなく customer、order ではなく transaction と呼ぶなら、AI もその言葉を使うべきだ。&lt;/p&gt;
&lt;p&gt;コンテキスト文書の価値は、情報量ではなく推測を減らすことにある。&lt;/p&gt;
&lt;h2 id=&#34;tdd-で生成速度を制御する&#34;&gt;TDD で生成速度を制御する
&lt;/h2&gt;&lt;p&gt;AI の危険は速さにある。昔は悪いコードを大量に書くにも時間がかかったが、今は数秒で数百行が出る。問題は速さそのものではなく、フィードバックループがないことだ。&lt;/p&gt;
&lt;p&gt;&lt;code&gt;tdd&lt;/code&gt; skill は RED-GREEN-REFACTOR を戻す。&lt;/p&gt;
&lt;ol&gt;
&lt;li&gt;ひとつの振る舞いに対して失敗するテストを書く。&lt;/li&gt;
&lt;li&gt;そのテストを通す最小実装を書く。&lt;/li&gt;
&lt;li&gt;リファクタリングする。&lt;/li&gt;
&lt;li&gt;次の縦スライスへ進む。&lt;/li&gt;
&lt;/ol&gt;
&lt;p&gt;重要なのは、ひとつずつ進めることだ。AI は実行し、人間は方向と境界を確認する。&lt;/p&gt;
&lt;h2 id=&#34;診断ループで複雑な問題を扱う&#34;&gt;診断ループで複雑な問題を扱う
&lt;/h2&gt;&lt;p&gt;バグに出会うと、多くの agent は答えを推測し、何度も修正して問題をさらに複雑にする。&lt;/p&gt;
&lt;p&gt;&lt;code&gt;diagnose&lt;/code&gt; は先にフィードバックループを作らせる。&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;再現する&lt;/li&gt;
&lt;li&gt;最小化する&lt;/li&gt;
&lt;li&gt;仮説を立てる&lt;/li&gt;
&lt;li&gt;観測やログを足す&lt;/li&gt;
&lt;li&gt;修正する&lt;/li&gt;
&lt;li&gt;回帰テストを足す&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;古い方法だが、AI コーディングでは特に重要だ。AI は試行が得意だが、根因に近づいているかを判断するにはレールが必要になる。&lt;/p&gt;
&lt;h2 id=&#34;アーキテクチャを定期的に見る&#34;&gt;アーキテクチャを定期的に見る
&lt;/h2&gt;&lt;p&gt;単発のタスクが通っても、コードベースが良くなったとは限らない。AI の小さな変更が積み重なると、モジュール境界がぼやけ、インターフェイスが複雑になり、テストしづらくなる。&lt;/p&gt;
&lt;p&gt;&lt;code&gt;improve-codebase-architecture&lt;/code&gt; のような skill は、現在のタスクから離れて全体を見る。&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;責務が混ざっているモジュールはどこか&lt;/li&gt;
&lt;li&gt;複雑すぎるインターフェイスはどれか&lt;/li&gt;
&lt;li&gt;テストしづらい経路はどこか&lt;/li&gt;
&lt;li&gt;ドメイン言語と合わない命名はどれか&lt;/li&gt;
&lt;li&gt;収束すべき重複ロジックはどれか&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;これは自動で大規模リファクタリングするためではない。構造化された観察と改善方向を出し、人間が判断するためのものだ。&lt;/p&gt;
&lt;h2 id=&#34;制限すべきは自由度&#34;&gt;制限すべきは自由度
&lt;/h2&gt;&lt;p&gt;この方法論の核心は単純だ。AI コーディングはモデルを自由に走らせることではなく、明確な目標、コンテキスト、テスト、停止条件を与えることだ。&lt;/p&gt;
&lt;p&gt;人間は問題定義、アーキテクチャ境界、業務上の取捨選択、受け入れ基準を担当する。AI はコード生成、テスト補完、反復修正、局所的なリファクタリングを担当する。&lt;/p&gt;
&lt;p&gt;AI が強くなっても、ソフトウェア工学の基礎は古くならない。要件整理、ドメイン言語、TDD、診断、アーキテクチャレビューは、むしろ重要になる。&lt;/p&gt;
&lt;p&gt;コードを書ける人は増える。差がつくのは、AI を保守可能で検証可能な工学体系に組み込めるかどうかだ。&lt;/p&gt;
</description>
        </item>
        
    </channel>
</rss>
