AIコーディングワークフローとは何ですか？
AIコーディングワークフローとは、エンジニアリング上の判断を手放すことなく、ソフトウェアタスク全体を通じてAIを利用するための再現可能な方法です。開発者は何をもって成功とするかを定義し、意味のある変更ごとにレビューを行います。コーディングエージェントはまずプロジェクトを調査し、アプローチを提案します。承認後、関連するファイルを編集し、プロジェクトのチェックを実行できます。
構造化されていないAIコーディングがかえって手間を増やす理由
構造化されていないAIコーディングは、コードがすぐに生成されるため速く感じられます。しかし本当のコストは後になって現れます。開発者が前提の食い違いを解きほぐしたり、当初の依頼範囲を超えて広がった変更を修復したりしなければならない場面です。
計画と実行が同時に進んでしまう
依頼内容が曖昧な場合、エージェントはすでにコードを書きながら、その機能が何をすべきかを決めることになります。その判断は開発者の意図と一致しないことがあります。例えば「ダークモードの切り替えスイッチを追加して」とだけ伝えた場合、エージェントはそのスイッチをどこに配置すべきか、またユーザーがアプリを閉じた後もその選択を記憶すべきかどうかを知りません。
大きすぎるプロンプトはレビューしづらい変更を生む
広い範囲のリクエストを出すと、エージェントはプロジェクト内のつながり合う多くの部分を一度に変更しようとします。個々のファイルは妥当に見えても、生成されたパッチ全体は開発者が自信を持って理解できるサイズを超えてしまうことがあります。例えば「設定ページを作って」というリクエストは、インターフェースだけでなく設定値の保存方法にも影響を及ぼす可能性があります。
コンテキスト不足は汎用的なコードを生む
コーディングエージェントは、見たことのないプロジェクトの慣習には従えません。関連するファイルやリポジトリの指示がなければ、既に存在する抽象化があるにもかかわらず新しい抽象化を導入してしまうことがあります。また、導入済みの依存関係のバージョンと合わないAPIを使ってしまうこともあります。
生成の速さは手直しのコストを隠す
生成にかかる時間は、納品にかかる時間ではありません。1分で生成されたパッチが、その後半日のデバッグを必要とすることもあります。より適切な指標は、明確な要件から、チームが保守を引き受けられる検証済みの変更に至るまでの時間です。
AIコーディングワークフロー全体像
以下のワークフローでは、開発者が意思決定の主導権を握りつつ、繰り返し発生する調査や実装作業をエージェントに任せます。
| 段階 | 人が担う役割 | AIが担う役割 | 成果物 |
|---|---|---|---|
| 定義 | 目標と制約を設定する | 曖昧な点を洗い出す | 承認済みの仕様 |
| 調査 | 対象範囲を確認する | 関連するファイルと依存関係を調べる | コンテキストマップ |
| 計画 | アーキテクチャとトレードオフを承認する | 順序立てたタスク計画を作成する | レビュー済みの計画 |
| 実装 | 範囲をコントロールする | 的を絞ったコード変更を行う | レビュー可能な差分 |
| 検証 | 期待される挙動を定義する | テストを実行し、失敗内容を確認する | テストの証跡 |
| レビュー | 最終的な判断を下す | リスクや矛盾点を洗い出す | 承認済みの変更 |
| リリース | 統合を許可 | 作業内容と残存リスクをまとめる | リリース証跡とともにレビューされた変更 |
Kimi Codeは、リポジトリ内のファイルを検査し、承認済みの編集を行い、プロジェクトの検証コマンドを実行することで、このループをサポートできます。
ステップ1：コードを依頼する前に、達成したい結果を定義する
実装方法を指定する前に、望ましい振る舞いを説明しましょう。影響を受けるユーザーやシステムを特定し、タスクの範囲を定め、変更後に確認できる受け入れ基準を加えます。
簡単な例で考えてみましょう。既存のWebアプリにダークモードを追加したいとします。コーディングエージェントに次のようなリクエストを出すこともできます。
エージェントはこれに基づいて行動できますが、足りない要件は自分で補わなければなりません。トグルをインターフェースの誤った位置に置いたり、ダークモードを1つのページにしか適用しなかったりする可能性があります。生成されたコードは技術的には動作しても、望んでいたユーザー体験にはならないかもしれません。
より役立つプロンプトは、エージェントが編集を始める前に結果を定義します。
このバージョンでは、エージェントに明確な目標を与え、勝手にプロダクトの意思決定を行わせないようにできます。また、開発者にとっても完成した作業を具体的に確認する手段になります。「機能が完成しているように見えるか」を尋ねる代わりに、明示された要件に照らして動作を確認できます。
ステップ2：適切なコーディングハーネスとモデルを選ぶ
モデルは、AIがコードをどれだけ理解し推論できるかを左右します。コーディングハーネスは、その推論をプロジェクト内で検証済みの変更にできるかどうかを左右します。両方を早い段階で選んでおくことで、タスクに対応できないツールを前提にワークフローを組んでしまう事態を防げます。
ループを完結できるハーネスを選ぶ
有用なコーディングハーネスは、スニペットを生成するだけではいけません。リポジトリへのアクセス、ファイルを編集する権限、プロジェクトの既存コマンドを実行する能力が必要です。タスクが複数のファイルに影響する場合は、計画立案の支援と明確な承認の仕組みも重要になります。
タスクに合わせてモデルを選ぶ
簡単な編集であれば、高速なコーディングモデルだけで十分な場合もあります。複雑なデバッグやファイル横断のリファクタリングでは、より強力な推論力と、周辺のコードを理解するための十分なコンテキストが役立ちます。モデルは、ハーネスが提供するツールとも確実に連携できる必要があります。
Kimi CodeとKimi for Codingを使う
Kimi Codeは、タスク単位の開発向けに完結したハーネスを提供します。見慣れないリポジトリを探索し、編集前に計画を立て、関連するファイルを更新し、実際のプロジェクトに対してテストを実行できます。ターミナル、ブラウザ、対応するIDEから利用できます。
サードパーティ製のコーディングツール向けに、Kimi Codeプラットフォームは安定版モデルKimi K3を提供します。このモデルは、クライアント側の設定を変更することなくアップグレードできます。より速いイテレーションが重要な場合は、高速モデルが同等のコーディング能力をより高い出力速度で提供します。
Kimi CodeとKimiモデルは、ワークフローの両面をカバーします。モデルがコードの推論を担い、ハーネスがその推論をレビュー可能な変更に変えます。
ステップ3：コーディングエージェントにプロジェクトを検査させる
達成したい結果が明確になったら、現在の挙動を制御しているコードの場所を特定するようエージェントに依頼しましょう。ファイルを変更する前に、探索によってタスクの範囲を絞り込む必要があります。
リポジトリの指示から始める
まずエージェントに、リポジトリ自体のガイドラインを確認させます。これは README.md や CONTRIBUTING.md、あるいはエージェント向けの指示ファイルに記載されていることがあります。ここで役立つのは、プロジェクトが実際に使用しているコマンド、コーディング規約、そして行ってはいけない操作です。
たとえば次のようなプロンプトを使います。
エージェントの応答には、読み込んだ指示ファイルの名前と、関連するコマンドの引用が含まれているべきです。もし提案されたコマンドがリポジトリ内に見当たらない場合は、実行する前にそのコマンドの出所を確認してください。
編集前に該当するコードを見つける
役立つコンテキストマップは、具体的なファイル名を挙げ、それぞれが重要な理由を説明するものです。大まかなディレクトリの一覧だけでは不十分です。関わっているはずの共有ユーティリティが応答に含まれていない場合は、計画を始める前にそのマップを修正してください。エージェントは、エントリーポイントから依存するモジュールへと処理の流れをたどる必要があります。また、既存のテストや、利用できるなら類似の実装も見つけるべきです。
必要な場合にのみ外部のコンテキストを追加する
コードベースだけでは答えが得られない場合に、外部のドキュメントを取り込みます。正確な公式ドキュメントのURLを提示するか、公式の情報源を探すようエージェントに依頼してください。ドキュメントは、リポジトリにインストールされているバージョンと一致させます。エラーログやissueの説明も有用ですが、プロンプトに含める前に認証情報や個人データは取り除いてください。
編集を許可する前に、作業ツリーを確認し、既存の変更点を記録しておきます。バージョン管理の一連の流れについては、ステップ8で扱います。
ステップ4：計画と実行を分ける
計画とコーディングでは、レビューで確認すべき観点が異なります。計画段階では、提案された方向性がシステムに適合するかどうかを判断します。実装段階では、承認した方向性が正しく守られているかどうかを確認します。
コードを書かせない計画専用のプロンプトを明示的に使います。
承認する前に計画を確認します。適切な場合には既存のプロジェクトの抽象化が使われているかを確認してください。要件に含まれていなかった新しい依存関係や公開APIの変更など、隠れたスコープの拡大がないか注意します。提案されているテストが、単に新しく書かれた関数を実行するだけでなく、要求された挙動を実際に示すものになっているか確認してください。
このフェーズの成果物は、承認済みの計画です。エージェントが詳細な応答を出したからといって「完了」とは限りません。前提条件やファイルの範囲が正確になるまで、自分で計画を編集するか、修正を依頼してください。
ステップ5：計画をレビュー可能なタスクに分割する
各実装タスクには、明確な目標を1つと、結果を検証する方法を1つ設けます。こうすることで、変更をレビューしやすい規模に保ち、問題が起きたときにも原因を見つけやすくなります。
例えば、ステップ1のダークモード機能は、次のようなタスクに分けられます。
既存のカラートークンとテーマ関連のスタイルを確認する。
テーマ設定の項目を追加し、ユーザーの選択を保存する。
共有レイアウトとコンポーネントにダークテーマを適用する。
設定メニューにテーマの切り替えを追加する。
テーマの切り替えと保存に関するテストを追加する。
主要なページに表示上またはアクセシビリティ上の問題がないか確認する。
機能全体を一度に実装させるのではなく、これらのタスクを順番に進めます。1つの実装タスクについては、次のようなプロンプトを使います。
期待される結果は、実際に実行されたテストを伴う、範囲の絞られたコード変更です。次のタスクに進む前に、その両方を確認してください。もしエージェントが設定の切り替え機能や無関係なコンポーネントの編集まで行っていた場合は、まずそれらの変更を分離するか元に戻してください。
エージェントがタスクに何度もつまずく場合は、タスクをさらに小さくします。例えば、永続化を実装する前に、まずテーマ設定の項目だけを追加させてみてください。タスクの範囲を狭めることで、エージェントが立てなければならない前提の数が減り、次に進む前に検証すべき点も明確になります。
ステップ6：実装・テスト・確認を短いサイクルで繰り返す
計画を管理しやすいタスクに分割したら、それらを1つずつ完了させていきます。目的と範囲が明確なうちに、各変更をレビューします。
各タスクについて、次のサイクルを使います。
まず差分を確認することから始めます。エージェントが、現在のタスクに必要なファイルだけを変更しているか確認してください。パッチに無関係なリファクタリングや、後のステップで予定していた作業が含まれている場合は、テストを実行する前にそれらの変更を取り除くか分離してください。
次に、リポジトリにすでに定義されている検証コマンドを使用します。これらは通常、package.json、プロジェクトのドキュメント、または CI 設定の中に記載されています。たとえば、npm スクリプトを使う JavaScript や TypeScript のプロジェクトでは、次のようなコマンドが用意されていることがあります。
まずは対象を絞ったテストを実行し、素早くフィードバックを得ます。それが通ったら、より広範なチェックへ進みます。正常に完了すればエラーは出ません。
これらのコマンドはあくまで一例です。プロジェクトが実際にどのパッケージマネージャーやスクリプトを使用しているかを確認せずに、そのままリポジトリにコピーしないでください。Python や Go のプロジェクトでは検証プロセスが異なりますし、同じ JavaScript のプロジェクト同士でもスクリプト名が異なる場合があります。
補足: Kimi Code でこのワークフローを実践する
Kimi Code は次の1行だけでなく、タスク全体のレベルで動作します。望む結果を伝えれば、関連するコードを見つけ、実装計画を提案し、必要なファイルを更新し、プロジェクトのチェックを実行できます。すべての手順を手作業でまとめる代わりに、レビューすべき絞り込まれた変更を受け取ることになります。
不慣れなコードベースをより早く理解する
Kimi Code はエントリーポイントから開始し、関連するモジュールを通じて実行フローをたどることができます。関連するテストや既存のプロジェクトのパターンを特定するため、手作業でファイルを集めたりリポジトリの仕組みを説明したりする時間を減らせます。
コード以外の情報もタスクに取り込む
開発の背景情報には、エラーのスクリーンショット、デザインの参考資料、図表、動作を記録したものなどが含まれることがよくあります。Kimi Code はソースコードとあわせてマルチモーダルな入力を利用できるため、実装がタスクの根拠となった証拠を反映しやすくなります。
実際のプロジェクトで変更をテストする
Kimi Code は編集後に、リポジトリに既存のテストや品質チェックのコマンドを実行できます。チェックが失敗した場合は、実際のエラー出力を読み取り、そのフィードバックをもとに作業を進めるため、一度も実行されたことのない単独のコード提案よりも安心感があります。
うまくいくワークフローを繰り返し使えるプロセスにする
Skills は繰り返し行うタスクの指示を保持でき、Hooks は重要な時点で事前定義したアクションを起動します。MCP はチームがすでに使っているツールと Kimi Code をつなぎ、Plugins はこれらの機能をまとめて、再利用や共有がしやすいセットアップにできます。
長時間かかるタスクを止めずに進める
短い1回のセッションでは完了できない作業には、/goal によって Kimi Code に達成すべき目標と完了条件を与えられます。継続するやり取りの中で進捗を追跡するため、毎回全体の目標を言い直さなくてもタスクを前に進められます。
ステップ7: メンテナーとして AI 生成コードをレビューする
変更を受け入れる前に、最終的な diff を自分の目で確認してください。要求どおりに動作するか、既存のプロジェクトに合っているかを確認します。
正確性
コードは受け入れ基準を満たしていますか。通常のユーザーフローと、少なくとも1つのエラーケースを確認してください。要求した挙動をテストがカバーしていることを確認します。
アーキテクチャ
コードはプロジェクトですでに使われているパターンに従っていますか。ロジックは適切なモジュールに配置され、不要な抽象化は避けるべきです。
セキュリティ
新しい入力が検証され、権限が正しく適用されているか確認してください。ログに機密情報や個人データが露出していないことを確認します。新しい依存関係は、受け入れる前にレビューしてください。
保守性
コードはエージェントの説明がなくても理解できるものであるべきです。名前は明確であるべきで、コメントはコードから自明でない判断についてのみ説明するべきです。
スコープ
diff に現在のタスクに必要な変更のみが含まれていることを確認してください。無関係なリファクタリング、予期しないインターフェースの変更、不要なフォーマットの変更は取り除きます。
エージェントが生成した要約はレビューの助けにはなりますが、コードを読むことの代わりにはなりません。自分で説明できないコードを本番に出してはいけません。
ステップ8: ワークフロー全体を通してバージョン管理を使う
バージョン管理を使うことで、AI が関わる作業を確認したり元に戻したりしやすくなります。ここでは1つの独立したステップとして扱っていますが、その保護はエージェントがファイルを編集する前から始まっています。作業ツリーは最初に確認しておき、既存の作業とタスク中に加えられた変更を区別できるようにしてください。
リポジトリのルートで開いたターミナルで、次のコマンドを実行します。
git status --short
git diff --stat
git diff作業ツリーがクリーンな状態であれば、git status --short の出力は何も表示されません。すでに変更されたファイルがある場合は、それを記録し、エージェントに上書きしないよう伝えます。各タスクの後には、差分を再度確認してください。検証済みの状態がバージョン管理のチェックポイントとして問題ないかどうかは、開発者が判断すべきです。
多くのファイルに影響しうる実験を行う場合は、別のブランチやワークツリーを使用します。並行して動くエージェントが同じ作業ディレクトリを編集しないようにしてください。各ワークストリームに明確なファイルの所有権を与え、チェックに通過した後にのみ統合します。
明示的な承認なしに、コーディングエージェントに履歴の書き換え、ローカルの変更の破棄、force-push、変更の公開を許可してはいけません。これらの操作は通常のファイル編集よりも影響範囲が大きく、別途判断が必要です。
ステップ9：コーディングセッション間でコンテキストを保持する
長時間のタスクは、1回の会話の枠を超えて続くことがよくあります。チャット履歴に頼るのではなく、リポジトリの成果物としてエンジニアリングの状態を保存してください。
以下を含む短い機能ドキュメントを保持します。
承認済みの仕様
承認済みの実装計画
完了したタスクと現在のTODO項目
当初の方針を変更した意思決定
すでに実行したコマンドと最新の結果
既知のリスクや未解決の課題
引き継ぎ用のプロンプトを使って新しいセッションを開始します。
応答は、ドキュメントおよび現在のリポジトリの状態と一致している必要があります。新しいセッションに続行を依頼する前に、食い違いがあれば解消してください。この引き継ぎにより、AIコーディングエージェントが不完全な会話履歴からプロジェクトの状態を再構築する必要が減ります。
マルチエージェントAIコーディングワークフローの仕組み
マルチエージェントAIコーディングワークフローでは、個別のエージェントにそれぞれ異なる役割を割り当てます。あるエージェントがリポジトリを調査している間、別のエージェントが完成した差分をレビューする、といった形です。その価値は、複数のチャットを同時に開くことではなく、責任を分担することから生まれます。
実用的な構成には、次のような役割を含めることができます。
プランナー： 要件をコードベースに対応付け、ファイルを編集することなく、順序立てた計画を提案します。
実装者： 独立した作業環境の中で、範囲を絞ったタスクを完遂します。
テスター： 受け入れ基準を確認し、独立した環境で不具合を再現します。
レビュアー： 実装が正しいという前提を置かずに、差分を精査して正確性や潜在的なリスクを確認します。
人間の統合担当者： 意思決定を承認し、マージの順序を管理し、統合後の結果を検証します。
マルチエージェントワークフローは、タスクをきれいに分割できる場合に最も効果を発揮します。すべてのエージェントに同じ承認済み仕様を与え、所有権を明確に割り当て、競合を防ぐために独立したブランチやワークツリーを使用してください。小さな修正や、単一の変更対象ファイルに依存するタスクの場合は、通常、単一のエージェントの方が効率的です。
Kimi Code は、独立したコンテキストを持つサブエージェントに、より大きなタスクを分割して割り当てることができます。Agent Swarm を使えば、複数のサブエージェントがタスクの異なる部分を並行して処理し、その結果をメインのワークフローに戻してレビューと統合を行うことができます。これにより、タスクの境界と最終承認をあなたの管理下に置いたまま、実行時間を短縮できます。
タスクに応じてワークフローを選ぶ
すべてのコーディングタスクに同じ量の計画が必要なわけではありません。単純な修正は素早く進められますが、複雑な変更やリスクの高い変更はリリース前により多くのレビューが必要です。
小さな変更： 関連するコードを確認し、焦点を絞った1つの編集を行い、関連するテストを実行し、差分をレビューします。
中規模の機能： 短い仕様書を作成し、実装計画を承認したうえで、作業をいくつかの小さなタスクに分けて完了させます。レビューの前に、より広範なテストスイートを実行します。
リスクの高い変更: 設計レビューとロールバック計画を追加する。認証、決済、データ移行に関わる変更では、セキュリティレビューと段階的リリースも必要になる場合がある。
マルチエージェントプロジェクト: すべてのエージェントに同じ仕様と明確なタスクの担当範囲を与える。それぞれの成果を統合した後、関連するテストをすべてもう一度実行する。
Kimi Code はこれらのワークフローそれぞれをサポートできる。単純なタスクには軽量なプロセスを使い、変更の取り消しが難しくなる、あるいはユーザーへの影響が大きくなるにつれて、計画とレビューを増やしていく。
再利用可能なAIコーディングワークフロープロンプト
このテンプレートは、どのコーディングエージェントでも使用できる。角括弧内の各項目を置き換えてから、エージェントに送信する。
これは Kimi Code の最初の指示として使うことができる。1つのプロンプトで機能全体をカバーしようとするのではなく、作業の進行に合わせて Current phase と Task を更新していく。
まとめ
信頼できるAIコーディングワークフローは、生成するコード量を最大化することを目指すものではない。誤った前提を早期に洗い出し、各変更をレビュー可能な状態に保つものだ。Kimi Code はコードの読み書き、シェルコマンドの実行、関連するWebページの取得を行い、タスクの進行に応じて動作を調整することで、このプロセスを支える。アーキテクチャと最終的なリリース判断の責任は、開発者に残る。まずは小さく検証可能なタスクから始め、プロジェクトのリスクに応じて必要な分だけプロセスを追加していく。
よくある質問
kimi、kimi web、kimi acpの3つのモードがサポートされていると記載されています。