『AI に使われた』と感じてから始めた3つのこと
はじめに
AI は便利だ。
しかし、AI を使っているといつの間にか AI に主導権を握られ、AI に使われているような状態になったことはないだろうか？
それは直接的にあなたが AI に使われるときもあれば、間接的にあなたが誰かの AI による成果物を経由して AI に使われてしまっているときもある。
この記事では、AI に使われないために私が普段からやっていることを書いている。
どういうときに AI に使われているか
まず、どういうときに使われているのか。私は以下のときに使われていると感じる。
- AI が生成したコードによって生み出されたバグを修正しているとき
- AI が生成したドキュメントをほとんど書き直しているとき
- AI が一度に生成した大量のコード・ドキュメントを読んでいるとき（そしてその中身がイケていないとき）
- AI に無駄な enter（accept）を押すことを強要されているとき
- AIが生成したことによる、意図の汲み取りが難しい PR やドキュメントのレビューに時間がかかるとき
などなど...
ちなみに、私が AI に使われているな〜と思ったあとは、謎の疲労感を感じるような気がする。
いい汗をかいた充実感というよりも、変な汗をかいちゃったな...ぐぬぬ...みたいな感じ。
どうすれば AI に使われないか
今回は3つ紹介する。
- 一気にやらせない/指示をサボらない
- why を聞く
- AI で問題を解くことに固執しない
一気にやらせない / 指示をサボらない
初期の頃は「Vibe Coding だ！うおおお！」と思い、一気にあれからこれまでやらせることが多かった。
しかし、蓋をあけると時間もお金も溶かしていたように思える。
もちろん、新規事業であったり PoC として内部の品質は後回しで、とにかく早く動くものを見たい動機であれば一気にやらせた方がよい場合もあるが、既存のレビュープロセスや品質基準が変わらないのであれば、ちいさく作っていった方がうまくいくし、結果的に AI に使われている感を抑えることができる。
具体的には、一度のプロンプトですべてをやってもらうのではなく、タスクを分解していくイメージ。
たとえば「画面を作って」ではなく、コンポーネントを作ったり、スキーマを定義したり、テストを書いたり...と、細かく指示を出すイメージだ。
それでもうまくいかないとき・自分が想定していないコードが出てくるときは、指示が曖昧であることが多い。
「画面を作って」と指示を出すと、全く関係がない環境ファイルの差分があったり、「コンポーネント側だけ修正して」と指示を出しても、意図しない形でテストコードまで修正されるなどさまざまである。
そのようなことがあり、私は AI に「何を」「どうして欲しいのか」を明確に伝え、それ以外の曖昧な部分に関しては何もやらないか、わからないなら逆に聞いてもらったり、todo コメントを残してもらうようにしている。
普段は Claude Code の Plan で「何を」「どうして欲しいのか」を伝え、手順や方向性に問題がなければ承認をするようにしている。（それでもブレるときは追加で「タスクの完了条件」も明記するが、そこまでやることは少ない。）
Plan にする理由は、修正されたものをあとから reject するよりも、先に修正の方針を reject した方がさまざまなコスト面（認知・時間・token など）でメリットを得られるからである。
ちなみに最初に計画を立てることは Claude Code: Best practices for agentic coding でもおすすめされている。
Ask Claude to make a plan before coding. Explicitly tell it not to code until you’ve confirmed its plan looks good.[1]
why を聞く
AI は how を自ら考え、何か動くものを作るまでは速い。
しかし、成果物を見たときに「なぜそうなった？」と思うことがある。
たとえば、A で作った方がいいようにも思える箇所を B を作ってきたとき。
昔はもう少し、1行に対して思いやこだわりがあったような気がしており、それをあまり考えずに AI は書いてくるような感覚がある。
そういうとき、私は「違う how はないのか」「なぜこうしたのか」「これのいい点と悪い点は？」とちょっと意地悪な質問を AI にしている。
嘘で固められた文章が羅列する時もあれば、実は訳があってそうしているときもあるので、とにかくまず聞いてみるようにしている。
一気に書かせることはほとんどなくなってしまったが、ある程度のボリュームがあるコードを書かせるときは、コードの上に why のコメントを残してもらうようにプロンプトに仕込んだりしている。
これによって、あとで成果物のコードリーディングをするときに「？」と思う時間を減らすことができる。
また、自分が答えをすでに知っているときは無理に why を尋ねる必要はないが、想定していなかった how で書いたときは「こうしてください」ではなく「どうしてそうしましたか？」を聞いてみると良い。
これは自身の研鑽のためでもある。
もしかしたら AI が書いたコードの方が正しいのに、人間が間違った知識を持っていたせいで、よくないコードを生成してしまう可能性があるからだ。
ちなみに AI に「こうしてください」と言うと AI は平気で「そうですね！それがいいと思います！」と言って、すぐ修正に取り掛かってしまうので、最初から答えを提示しないことがポイント。
もちろん、明確に間違いだとわかるコードについてはこの限りではないが、それでも私はやっておいて損はないと思っている。
もし試していなければ今からでもいいので、少しでも違和感を感じたコードに関して、why を AI に聞いてみて欲しい。
AI で問題を解くことに固執しない
Claude Code のような定額制を使っている場合、1回だろうが100回だろうが支払うコストは変わらない。
「よっしゃ、使い放題じゃん」と思って何度もトライしてみるが、期待通りの結果が得られない。
そういう場合、潔く AI を使わずに手で書くようにしている。その方が速いし何より疲れないからだ。
AI を使うことが近道であれば良いが、物によっては AI を使うことが遠回りのこともある。
しかし、いつの間にか問題を解くことが目的なのに、AI を使うことが目的にすり替わっていることがある。
あくまで、問題を解くための手段として AI であったり自らが手を動かす選択肢があるわけで、それを我々は常に選択できる立場にあるのに、無理に AI で解こうとするから仕事が終わらない...みたいな。
最初はどれくらい AI が使えそうか調べるために、無理にでも AI に全てのタスクをお願いしていたが、最近はそうすることも減ってきている。
AI を使うこと自体は変わらないのだが、AI に素振りしてもらっている間によい方法が浮かんだり、AI に指示を書いている途中で思いついて、すぐに終わりそうなものである場合（かつ AI が間違えそうな気がするとき）は、AI の process を止めて、自分で手を動かすようになった。
よく途中で諦める風刺画をネットで見かけるが、1列・2列を AI で問題を解こうとする人とすると、さっさと3列目の人（AI を使わず、より良い手段で問題を解決する道を選んだ人）になった方が良いのではないだろうか。
途中で諦める風刺画
AI を使わず、より良い手段で問題を解決する道を選んだ人（AI が作りました）
さいごに
AI が登場してから、私は AI を使っている立場だと勝手に思っていたが、思い返すと主導権が向こうに渡っていたときもあったように思える。
私だけではなく、周りで AI を活用しているチームメンバーにも、そういう一瞬があったような感じがうっすらとあった。
そのようなことが重なり、AI に使われないためにどうすればいいかを考えて、今回紹介した3つの方法が自分の中で確立されていった経緯がある。
また、この課題は自分だけの問題ではなく、チームの中で共有してみることで、より良い解決策が見つかるかもしれない。
チームメンバーの誰かが AI に使われて始めてしまうと、その人だけではなく周りのチームメンバーにもあまり良くない影響を与えてしまうことがある。
今回の話は個人の単位ではなく、チーム単位でも意識したい。
個人としてもチームとしても、より良い AI の活用方法を確立するために、また明日も AI を使っていこうと思う。
Discussion