メインコンテンツへスキップ

AI駆動開発の完成条件の書き方 — AIに任せる前に書く3つ

AIエージェントに開発を任せたいものの、「出てきたコードが正しいのか判断できない」「任せたら思わぬところまで書き換えられた」と困っている開発経験者と、そのチームを預かる方に向けた記事です。答えは、任せる前に3つを書くことです。どうなれば完成かを確かめられる言葉で書き(完成条件)、AIが触ってよい範囲に線を引き(ガードレール)、それを自動テストで機械的に確かめます。そのうえで、最後に変更点を人が読みます。この順で進めると、AIが速く書いても、品質と責任は人が持てます。この記事では、その書き方を架空の業務シナリオで示します。

要約: AI駆動開発で品質を保つには、AIに任せる前に、確かめられる言葉で完成条件を書き、AIが触ってよい範囲にガードレールを引き、自動テストで機械的に確かめ、最後に人が変更点を読みます。AIが実装し、人が品質と責任を担う分担です。
無料相談(30分・オンライン)を予約する
30分・無料・Zoom。開発経験者コースが合うか、職務と経験から一緒に確認します。

AI駆動開発とは(この記事での意味)

この記事では、AIエージェントが実装を進め、人が方針・レビュー・責任を担う開発の進め方を「AI駆動開発」と呼びます。AIエージェント(AIコーディングエージェント)とは、指示を受けて自分でコードを書き、コマンドを実行し、結果を見て直すところまで進めるAIのことです。

AIにどこまで任せるかは、組織や使う道具によって変わります。そこでこの記事は範囲を絞り、任せる側の人が、AIに渡す前に書いておくものだけを扱います。ツールの比較や、AI駆動開発のメリット・デメリットの一般論は扱いません。

任せる前に書くものは3つ

AIに任せる前に書くのは、完成条件・ガードレール・自動テストの3つで、順番もこのとおりです。

書くもの何を決めるかひとことで
完成条件何が起きれば「完成」と言えるか作るものの合格ライン
ガードレールAIが触ってよい範囲と、守らせる線作業の範囲と禁止事項
自動テスト完成条件を機械で確かめる仕組み合格ラインの自動判定

順番に意味があります。完成条件がないと、テストに何を書けばよいか決まりません。ガードレールがないと、AIはテストを通すために関係のない場所まで書き換えることがあります。3つがそろってから実装を任せ、最後に人が変更点を読みます。以下、手順1〜5で順に説明します。

手順1 完成条件を「確かめられる文」で書く

完成条件は、「使いやすい」のような感想ではなく、「この操作をすると、この結果になる」という操作と結果の文で書きます。誰が確かめても同じ判定になる文であることが要点です。

例として、株式会社Qukuri(ククリ)の AI駆動開発講座のページ(/ai-training)に載せている、架空の題材「備品の貸出管理」の完成条件を引用します。

  • 備品の貸出を登録すると、一覧に1行増える
  • 名前の一部を入れて検索すると、その備品の貸出だけが一覧に出る
  • 「返却済みを除く」にチェックすると、まだ返していない貸出だけが出る

(出典: qukuri.co.jp/ai-training/「完成したと言える条件」の記入例。2026-11-08 確認)

どれも「何をしたら」「何がどうなるか」が書いてあるので、画面で操作しても、テストコードにしても、合否が分かれません。

次の表は、曖昧な書き方を確かめられる書き方に直した対比です。この表は記事の説明用に作った架空の例で、講座の教材そのものではありません。

曖昧な書き方確かめられる書き方(説明用の架空例)直した点
検索がちゃんと動く名前の一部「プロジェ」で検索すると、「プロジェクター」の貸出だけが出る。該当がなければ「該当なし」と表示する入力と結果、該当なしの場合まで書いた
入力ミスを防ぐ返却予定日が貸出日より前だと登録できず、その旨を画面に出すどの入力を、どう扱うかを書いた
動作が速い(測り方と基準値を人が決めてから、「〇件のとき、検索結果が〇秒以内に出る」の形で書く)数字を決めないまま書かない
きれいなコードにする既存のテストがすべて通り、静的解析(lint)の警告が増えない機械で判定できる言葉に置き換えた

書き終えたら、「この文だけを読んだ別の人が、合否を判定できるか」で見直します。判定できない文は、まだ完成条件になっていません。

手順2 ガードレールを引く

ガードレールとは、AIが触ってよいファイル、触ってはいけないもの、実行してよいコマンドを先に書いておくことです。変更が範囲を越えそうになったら、AIに作業を止めさせて人に戻す、という決まりまで含めます。

次は、備品の貸出管理に検索機能を足す作業を想定した、説明用の架空例です。

区分書く内容(説明用の架空例)
触ってよい貸出の一覧・検索の画面と処理のファイル、それに対応するテストのファイル
触ってはいけないログイン・権限まわり、環境設定ファイル(接続先や秘密情報を置くファイル)、既存テストの期待値
実行してよいコマンドテストの実行、静的解析の実行、ローカルでの起動
人の確認が要るものライブラリの追加、データベースの構造の変更、リモートへの反映(push 等)
止める条件上の「触ってはいけない」に手を入れる必要が出たら、変更せずに理由を書いて止まる

ポイントは「既存テストの期待値」を触らない側に入れることです。テストが通らないときに、コードではなくテストのほうを書き換えて通してしまうのを防げます。

また、試すのはローカル環境とテスト用のデータで行い、本番環境と実データには触れないことも、ガードレールの前提として書いておきます。

AI駆動開発講座の開発経験者コースでも、第2回の主題は「骨格を作り、ガードレールを引く」です(/ai-training)。講座での具体的な進め方は、御社の業種に合わせた架空の業務シナリオで行います。

手順3 完成条件を自動テスト・CIにする

手順1で書いた完成条件を1つずつ自動テストに対応させ、テストが通ることを「完成の合図」にします。CI(変更のたびに自動でテストを回す仕組み)に載せておけば、毎回同じ基準で確かめられます。

対応のさせ方の説明用の架空例です。

完成条件テストで確かめること(前提 → 操作 → 期待)
貸出を登録すると、一覧に1行増える一覧が2件の状態 → 貸出を1件登録 → 一覧が3件になり、登録した備品名が含まれる
名前の一部で検索すると、その備品の貸出だけが出る「プロジェクター」「ホワイトボード」の貸出がある → 「プロジェ」で検索 → 「プロジェクター」の行だけが出る
「返却済みを除く」で未返却だけが出る返却済み1件・未返却1件 → チェックを入れる → 未返却の1件だけが出る

AIにテストコードを書かせることもできます。その場合も、前提と期待値は人が決めます。 期待値までAIに任せると、AIが書いた実装に合わせた期待値になり、テストが「実装をなぞるだけ」になりやすいからです。完成条件の表をそのままAIに渡し、「この表のとおりにテストを書く。期待値は変えない」と指示すると、人が決めた合格ラインを保てます。

開発経験者コースの第3回の主題も「完成条件を、機械が検証できる形にする(自動テスト・CI)」です(/ai-training)。

手順4 境界の内側でAIに自律修正させる

テストが失敗したら、手順2で決めた範囲の中に限って、AIに原因を調べて直し、テストを再実行するところまで任せます。範囲を越える修正が必要になったら、そこで止めて人に戻します。

この「失敗 → 修正 → 再実行」の繰り返しを毎回口頭で指示していると、指示の抜けや揺れが出ます。完成条件・ガードレール・使うコマンド・止める条件を1つの指示文にまとめ、次の作業でも同じものを使えるようにしておくと、任せ方が安定します。

開発経験者コースでは、第4回で「手順を再利用できる形にし、境界の内側で自律修正させる」を扱います(/ai-training)。

手順5 変更点を人が読む

テストがすべて通ったら、最後に人が変更点(差分)を読み、完成条件とガードレールに照らして確かめます。テストは書いたことしか確かめないので、テストに書いていない問題は、人が読まないと見つかりません。

差分を読むときは、次の順に見ると漏れが減ります。

  1. 変わったファイルが、ガードレールの「触ってよい」範囲に収まっているか。 範囲外のファイルが混ざっていたら、理由を確認します。
  2. テストが減ったり、弱くなったりしていないか。 削除されたテスト、緩められた期待値、スキップされたテストがないかを見ます。
  3. 完成条件ごとに、対応するテストがあるか。 手順3の表と1対1で照らします。
  4. テストを通すためだけの書き方になっていないか。 特定の値だけを特別扱いするような処理がないかを見ます。
  5. 人の確認が要るもの(ライブラリの追加など)が、確認なしに入っていないか。

当社の受託開発でも、この分担で進めています。AIエージェントが実装とテストコード作成を進め、AIが生成したコードはエンジニアがレビューし、自動テストで動作を検証します。サービスページでは「品質はエンジニアの全行レビューで担保します。」「品質と責任は人が担います。」と書いています(qukuri.co.jp/ai/、2026-11-08 確認)。

うまくいかないときの見直し先

AIに任せてもうまくいかないときは、3つのうちどれかが足りていないことが多いので、兆候から見直し先を探してください。

兆候見直し先直し方
出てきたものが「なんとなく違う」が、どこが違うか言えない完成条件操作と結果の文に書き直す。「該当なし」「入力ミス」の場合も書く
頼んでいない場所まで書き換えられるガードレール触ってよい範囲を狭め、止める条件を書く
テストは通るのに、画面で触ると動かない自動テストテストの期待値が完成条件と一致しているか、人が決めた値か確かめる
修正のたびに別の場所が壊れる自動テスト・ガードレール既存テストを触らない側に入れ、毎回すべてのテストを回す
差分が大きすぎて読み切れない作業の切り方1回に任せる範囲を、完成条件1〜2個分に小さくする

どの場合も、AIへの指示を足す前に、人が書くもの(完成条件・ガードレール・テストの期待値)から見直すと、原因を絞りやすくなります。

一人で試すか、型を教わるか

ここまでの手順は一人でも試せます。チームで同じ型をそろえたい場合や、自力で使えるところまで練習したい場合は、当社の AI駆動開発講座「開発経験者コース」がこの型を扱います。

コースが掲げる「生かすもの」は「完成条件を書き、守らせる線を引き、自動テストで確かめ、変更点を人が読む。」です。修了時にできることは「AIに開発させる型(完成条件・ガードレール・自動テスト・境界つきの自律修正)を、御社の業種に合わせた架空の業務シナリオに自力で使える」ことです(/ai-training、2026-11-08 確認)。

回主題(/ai-training の記載どおり)
第1回開発環境を講師と一緒に作り、完成条件と計画を決める
第2回骨格を作り、ガードレールを引く
第3回完成条件を、機械が検証できる形にする(自動テスト・CI)
第4回手順を再利用できる形にし、境界の内側で自律修正させる
第5回(両コース共通)御社の業種に合わせた架空の業務シナリオで、応用課題に自力で着手する
第6回応用課題を仕上げ、社内適用を設計する(修了判定)
  • 形式: オンライン、1クラス1〜3名、120分×全6回(週1回・約6週間)
  • 対象: 何らかの言語で業務システムを開発した経験がある方
  • 演習は架空の会社・架空のデータによる業務シナリオで行います。本講座は開発の代行ではなく、受講者ご自身がAIを操作します。

料金・必要な環境・修了条件は /ai-training をご覧ください。人材開発支援助成金の対象となる可能性がある講座です。申請は御社が行います。流れは 助成金を使う場合の流れ にまとめています。

AIエージェントでの開発そのものを依頼したい方は、AI駆動開発(受託)のページ をご覧ください。

よくある質問

AI駆動開発の「完成条件」とは何ですか?

何が起きれば完成と言えるかを、操作と結果で書いた文です。「備品の貸出を登録すると、一覧に1行増える」のように、誰が確かめても同じ判定になる形にするのが要点です。

完成条件とガードレールは何が違いますか?

完成条件は「作るものの合格ライン」、ガードレールは「AIが触ってよい範囲と守らせる線」です。完成条件は結果を決め、ガードレールは作業のしかたを決めます。

自動テストが通れば、コードを読まなくてもよいですか?

いいえ。テストは書いたことしか確かめないので、変更点は人が読みます。当社の開発でも、AIが生成したコードはエンジニアがレビューし、自動テストで動作を検証しています。

プログラミング経験がなくても試せますか?

この記事は開発経験のある方向けです。プログラミング経験がない方は、小さな業務ツールを自分のPCで動かすまでの手順を 非エンジニアが Claude Code で小さな業務ツールを作る流れ にまとめています。

開発経験者向けの講座では何を学べますか?

完成条件・ガードレール・自動テスト・境界つきの自律修正という、AIに開発させる型を、御社の業種に合わせた架空の業務シナリオで自力で使えるようになることを目指します。1クラス1〜3名、オンライン、120分×全6回です。

無料相談

開発経験者コースが御社の社員に合うかどうかは、無料相談で一緒に確認できます。30分・無料・Zoom で、職務と開発経験をうかがいながら、コースの選び方から考えます。

無料相談(30分・オンライン)を予約する
30分・無料・Zoom。開発経験者コースが合うか、職務と経験から一緒に確認します。
  • コースの内容と料金を見る: /ai-training
  • AIエージェントで開発を依頼したい方: /ai