最近の記事
-
Systems of Record in the AI Age
https://clementvouillon.substack.com/p/systems-of-record-in-the-ai-age
-
論文:Software Architecture Meets LLMsについて
https://arxiv.org/pdf/2505.16697
-
ソフトウェア開発におけるAIの牽引、伴走、追従
Claude Code定額プランの開始から1年。AI(以下、AI)は私の開発スタイルを大きく変えました。少し前にReactのチュートリアルを頼りに2ヶ月かけて作ったバグだらけのWebアプリを、今では1日でデプロイできます。 退屈な実装、設計の壁打ち、時にはメンターとして、AIは常に傍にあり手放すことはできない存在となりました。この記事は私のAIとの向き合い方を改めて見直し、価値のある使用法とはどういったものかを言語化するために作成しました。 この記事で扱うAIの用途は、業務における要件定義・設計・実装・テストの開発フェーズです。これらは依存関係ではなく反復的なプロセスとして捉えています。VibeCodingのように出力をノーチェックで受け入れるスタイルは扱わないこととします。 私は普段の業務でClaude（ブラウザ版）とClaude Codeを使っています。タスクに取り組むとき、必要な知識をどれだけ自分が理解しているかを常に意識しています。 理解度は3段階です。 完成形を具体的にイメージできる 知識はあるが、さらなる改善の余地を感じる 理解が足りず、AIの出力をレビューする自信がない この記事ではそれぞれ牽引・伴走・追従と呼びます。 課題領域を十分に理解し、完成形を具体的にイメージできる状態です。時間さえあれば迷わず完了できる。退屈な作業になりそうだと予想できる。そんなタスクが該当します。 この状態でAIが生む価値は時間短縮です。頭の中のイメージを出力させるために、タスクを独立した小さな単位に分割し、それぞれに適切なコンテキストを与えます。 この進め方はチーム運営に似ています。タスクごとに新しいチャットを使い、/clearで状態をリセットする。リセットが不都合なら、タスクの分割か設計に問題があると判断します。 これはマイクロマネジメントそのものです。自律性の高い人間のチームにはやりませんが、AIにはここまでやらないと成果物の質を信頼できません。人間のチームが共有する暗黙のコンテキストは膨大で、その全てをAIに伝えるのは困難です。だからこそ、プロジェクト全体を見渡してタスクを組み上げるのは人間の責務です。 ただし、本当にAIを牽引できる場面は多くありません。自分の理解が十分だという誤認、コードからモデルへのフィードバックの欠如、期待を超える出力への認知バイアス。これらを考えると、時間短縮を目的にAIを使うハードルはかなり高いと感じています。 ボイラープレートの記述や既知のインフラ層の実装などであればこの状態を維持できそうではあるものの、上記のリスクを踏まえると自信を持てる場面はやはり稀です。 知識はあるが、もっと良いやり方がありそうだと感じている状態です。自力でも完了できるが最善かどうかは確信が持てない。そんなタスクが該当します。 この状態でAIが生む価値は視野の拡張です。自分のアイデアをぶつけて、別の視点や知らなかったアプローチを引き出します。設計方針の壁打ち、実装パターンの比較、コードレビュー的な対話がこれにあたります。 牽引との違いは、AIの出力から学ぶ姿勢があることです。牽引では自分のイメージを忠実に出力させますが、伴走ではAIの提案に「なるほど」と思える余地を残します。自分の知識を起点にしつつ、AIの出力で視野を広げる。この往復が伴走の核です。 ここで重要なのは、AIの提案を受け入れる基準を自分の中に持つことです。知識があるからこそ、AIの提案の良し悪しを判断できます。根拠を尋ね、自分の理解と照らし合わせ、納得できたものだけを採用する。必要に応じて足りない知識は自らwebや書籍などから補充し、最終的に取捨選択ができる点が、次に述べる追従との決定的な違いです。 私はこの状態が最も生産的だと感じています。成果物の質そのものが上がる実感があり、設計に迷ったときにAIと対話し、自分では思いつかなかった選択肢に気づく。この体験は牽引では得られないものでした。 課題領域への理解が足りず、AIの出力を正しく評価できない状態です。何が正解かわからない。AIが出したものが妥当なのか判断する軸がない。そんなタスクが該当します。 この状態でAIに求めるのは学習の足がかりです。未知の技術領域に踏み込むとき、AIにまず全体像を示してもらい、自分が何を理解していないかを把握します。ドキュメントを読む前の地図のような使い方です。 ただし、この状態でAIの出力をそのまま採用するのは危険です。レビューする力がない以上、出力の誤りや不適切な設計を見抜けません。動くコードが出てきても、それが保守可能か、セキュアか、チームの方針に合っているかを判断できない。ここにこの状態の本質的なリスクがあります。 だから追従状態での目標は、成果物を作ることではなく、伴走状態に移行することです。AIの出力を手がかりにドキュメントや書籍を読み、基礎を固める。理解が深まれば、AIの提案を評価できるようになる。そこで初めて伴走が始まります。 追従していると自覚できること自体が重要です。理解が足りないまま牽引しているつもりになるのが最も危うく、自分の立ち位置を正直に見つめることが、AIと健全に付き合う出発点だと考えています。 ここまで3つの状態を整理してきました。改めて振り返ると、AIの価値はどの状態でも等しいわけではありません。 牽引は時間を短縮しますが、それを安全に行える場面は限られています。追従は学習の入口にはなりますが、成果物の質を担保できません。伴走だけが、時間と質の両方を引き上げる可能性を持っています。ここでの時間効率は短期的なものではありませんが、ソフトウェア品質の向上は長期的には開発の敏捷性に寄与します。 つまり、AIの価値を最大化するには、できるだけ多くのタスクを伴走状態で扱えるようにすることが鍵です。 そのためには自分の知識を広げ続けるしかありません。追従している領域は学習で伴走に引き上げる。牽引しているつもりの領域は、本当に牽引できているか疑う。AIに対する自分の位置を正確に見定めることも肝要です。そのために使用者が持つ知識も大切な価値であることを認識してAI登場以前と変わらない学習を続けることが重要だと考えます。