TL;DR
- AIにどこまで任せられるか、どこから人間のレビューが必要かは、タスクの種類とモデルの組み合わせで変わる。
- 解決策の数が少なく、失敗しても戻しやすい作業ほど任せやすい。解決策が無限にあり、プロダクトの方針や将来のメンテナビリティに影響する作業ほど、AIと壁打ちしながら人間が意思決定する。
- この判断は一度ルール化して終わるものではない。各社の各モデルを使い倒し、自分の作業における信頼感を肌感覚として持つことが重要だと思う。
AIの能力とレビューの必要度は感覚で決まる
「AIがどの程度できて、AIがどの程度レビューを必要とするか」は、数字だけでは測りにくいものです。
同じ指示でも、モデルによって出力の質や考え方の深さは変わります。また、同じモデルでも、UIの軽微な修正とDBスキーマ設計では、任せられる範囲がまったく違います。
だから私は、AIを使うなら、各社の各モデルを実際の作業で使い込んで、自分なりの肌感覚を持っておくことが重要だと考えています。
これは「このモデルは常に正しい」と信じることではありません。上司が部下に仕事を依頼するときに、「この粒度の指示なら、どの程度のアウトプットが返ってくるか」を経験から判断する感覚に近いものです。相手への信頼感や、意思決定の感覚がどの程度同期しているかを、タスクごとに見極めていきます。
まず見るのは、解決策の数
タスクを見たとき、私が最初に意識するのは、その課題を解決する方法をいくつ想像できるかです。
解決策がほぼ1つの作業
たとえば「XというUIの色を白からグレーに変更する」のような作業です。指示の意味について、他の解釈をする余地がほとんどありません。
このような変更は、AIにかなり任せやすいものです。もちろん変更箇所や画面を確認しますが、プロダクトの方針を決めるための深いレビューまでは必要になりにくいと感じています。
解決策が3〜4個ある作業
複数の実現方法が考えられる場合は、AIに実装を任せる前に、選択肢とトレードオフを確認します。
この段階では、AIに案を出させること自体が有効です。ただし、どの案を採用するかは、既存の設計や今後の拡張性と照らし合わせて判断します。
解決策が無限にある作業
プロダクト上の解決策が無限にあり得る場合、いきなり実装を依頼することはしません。AIと壁打ちをしながら、そもそも何を作るのか、どのスコープで解くのかを決めていきます。
ここでAIに期待するのは、最終決定を任せることではありません。自分の考えを言語化し、選択肢を比較し、見落としていた論点を出してもらうことです。
KIBAKOでの改善メモ設計
私が開発している、オンラインでボードゲームのプロトタイプを作成できるサービス KIBAKO で、まさにこの判断が必要になったことがあります。
KIBAKOには、ボードゲームを作る制作ルームと、実際にプレイするためのプレイルームがあります。テストプレイ中に見つかった改善点を、制作ルームへスムーズに持ち帰り、次のテストプレイに向けた制作につなげたい。これが今回の課題でした。
難しかったのは、「改善メモ」という機能を作ること自体ではありません。次のような方針を決める必要があったことです。
- 改善メモは、どのスコープで持つのか
- ユーザーはどこから入力し、どこで閲覧するのか
- どの権限の参加者に、どこまで見せてよいのか
- 複数のプレイルームをまたいだとき、メモをどう扱うのか
このような課題は、解決策が無限にあります。そこでAIと何度も壁打ちをしながら、プロダクト運営者としての方針を決めていきました。
最終的には、複数のプレイルームと、それらの元となる制作ルームを横断する「プロジェクト」に改善メモを紐づけることにしました。メモには、どのプレイルームで作成されたかも記録します。
一方で、単体のプレイルームにしか権限がない参加者には、そのプレイルームで入力されたメモだけを閲覧できるようにしました。閲覧のみで、プロジェクト全体のメモを編集できるわけではありません。
これが唯一の正解だとは、まだ思っていません。それでも、現在のユースケースと後の拡張性を考え、この仕様で確定して実装しました。こうした意思決定は、AIに丸ごと任せるのではなく、AIとの対話を使って自分が行う領域だと感じています。
不可逆性があるものは、レビューの深さを上げる
解決策の数とは別に、私が慎重になるのが「その変更は不可逆か？」という観点です。
DBスキーマ変更は、場合によっては元に戻せません。一度そのスキーマで運用を始めると、ユーザーの貴重なデータが入り始め、あとから大きく変更することが難しくなります。
そのため、DBマイグレーションでは、単にマイグレーションファイルが動くかだけを見ません。
- ユーザーデータが入る前に戻せるか
- ユーザーデータが入った後に、どのようなデータ移行が必要になるか
- 失敗した場合に、どこまで切り戻せるか
- 将来の機能追加やメンテナンスにどんな制約が残るか
まで考えます。ユーザーやシステムの今後の方向性、メンテナビリティへのインパクトが大きいものほど、レビューの必要度は高くなります。
モデルは細かく切り替えず、普段使いの費用対効果を磨く
私は、タスクごとにAIモデルを細かく切り替えるのが得意ではありません。そこで、普段の作業を最も効率よく進められる、安価なデフォルトモデルを見つけて使い込むようにしています。
2026年8月3日時点では、Codexの$100 Proプランを使い、普段は 5.6 Luna High あたりをデフォルトにしています。
一方で、解決策が複数あるタスク、DBスキーマ設計のレビュー、プロダクトやシステムの今後の方向性に大きな影響があるタスクでは、最初から Terra や Sol に上げます。effortもタスクに応じて調整し、仕様となるMarkdownファイルをAIと一緒に作っていきます。
大切なのは、最初の出力が浅かったから後から上位モデルへ切り替えることではありません。そのタスクが持つ不確実性や影響範囲を見て、最初から必要なモデルとeffortを選ぶことです。
私のレビューは、コードより仕様Markdownを中心にする
AIに実装を任せた後、私はコードを最初から最後まで同じ密度で読むわけではありません。主には、AIと実装方針のMarkdownを一緒に作り、その計画について気になったポイントを詳しく説明させます。
壁打ちの中で、たとえば次のような問いを投げます。
- なぜこのデータのスコープにしたのか
- 別の設計にした場合のトレードオフは何か
- 権限のないユーザーから何が見えてしまう可能性があるか
- 将来この機能を拡張するとき、どの部分が制約になるか
- 失敗した場合に、どの状態まで戻せるか
最終的には、仕様Markdown全体を確認します。最初に解決したかった課題と、決まった実装方針が一致しているかを見ます。
つまり、レビューの対象はコードだけではありません。AIがどのような考え方でそのコードにたどり着いたのか、そしてその考え方がプロダクトの目的と合っているのかをレビューしています。
使い込んで初めて、任せられる範囲がわかる
AIの能力とレビューの必要度は、モデルのスペック表だけでは判断できません。
実際に自分のプロダクト、自分のコード、自分の指示の出し方で使い続けて、どのくらいの説明なら意図を理解するのか、どの程度の設計なら安心して任せられるのかを知る必要があります。
その肌感覚は、モデルごとに違います。あるモデルでは安心して任せられるタスクが、別のモデルでは壁打ちを増やした方がよいかもしれません。だからこそ、各社の各モデルを実際に使い倒し、自分の作業における信頼感を持っておくことが重要です。
最初から完璧な判断基準を作る必要はありません。まずは一つのモデルを普段使いにして、解決策の数、不可逆性、将来への影響という観点で、任せた結果とレビューで見つかったことを少しずつ覚えていけばよいと思います。
まとめ
- 解決策がほぼ1つで、失敗しても戻しやすい作業はAIに任せやすい。
- 解決策が複数ある場合は、AIに案を出させつつ、人間がトレードオフを判断する。
- 解決策が無限にあり、プロダクトの方針に関わる場合は、AIと壁打ちしながら人間が意思決定する。
- DBスキーマ変更のように不可逆性やユーザーデータへの影響がある作業は、深くレビューする。
- 普段使いのモデルを使い倒し、モデルごとに「どの程度任せられるか」という肌感覚を持つ。
AIにどこまで任せられるかは、誰かが決めた固定ルールではありません。自分の仕事でAIを使い続ける中で、少しずつ磨いていく判断力なのだと思います。