AIと仲良く仕事するために考えたこと - バウムクーヘンコードを眺めながら

はじめに思うこと

2025年も終わりを迎える今日この頃ですが、生成AIを巡る目まぐりしい変化・発展は続き日々、それを眺めていると飽きることはありません。 私自身もAIを良き相棒ととらえ、自身の仕事の効率化や考えを整理する際の壁打ち相手として日々活用していますが、その中でもAIがイマイチだなと思うことが最近いくつかありました。 特にAIコーディング。何となく自身のAIの使い方・頼り方に問題があるのでは？と思い改めてAIがどんなことを得意とし、逆に苦手とするのか調べてみた。

先に結論

• 私はAIを否定するつもりはない、むしろ有用なケースではどんどんAIを活用し、仕事の効率化を図るべき（人間はもっと楽に生きましょう）
• ただし、AIはすべてを解決してくれる万能薬ではないと思っていて、用法容量を守らないと思わぬ副作用に苦しむことになりかねない
• 適材適所、AIが得意とすることはAIに任せ、AIが苦手とする部分は任せない、もしくはAIが理解できるレベル感に作業ブレイクした上で任せる必要がある、結局はマネジメント力が求められる

発生した事象

ちょっと気になる部分があり、試しにAIに既存のプログラムの改修を依頼することがありました。具体的にはこのブログのダークモード切替挙動の改善。簡単にWEBで調べたり別途壁打ちして得られた情報をもとに、ざっくりAIにコードの修正を投げてみた。 結果、それっぽいものが出来上がりましたが。。。期待した動きにならず、エラーも大量発生していたため、それを伝え再修正をしてもらいました。修正→確認を何度か繰り返して、最終的に動くものが出来上がったのですが。。。あらためてAIが手を加えたコードを確認したところ、

• 無意味な条件分岐
• 似たような処理の羅列
• エラーを無理やりつぶす例外処理

が幾重にも、あたかもバウムクーヘンのように積みあがった素敵な状態となっているではありませんか！ さすがにこのままでは気持ち悪い、かつ後々トラブルの原因となりうるため、このバウムクーヘンコードを一層ずつ剝がしながら、不要なロジックの削除、イケてない記述を書き直すことを余儀なくされました。

AIが書いたものが期待通りのものか見直すこと自体は至極当然であり必要なことだと考えていますが、今回に関しては、プログラミング初心者がとにかく動くことだけを目指しtry and errorを繰り返したぐちゃぐちゃコードをレビューしているような気分になり。

AIってこんなに考えずに突き進む存在だっけ？と疑問に思ったことをきっかけに、あらためてこの経験をAI相手にしばらく壁打ちして何が悪かったのか考えてみました。

どうしてこうなった。。。

壁打ちして分かったこととして、AIの特性上、こういった既存コードの修正のような作業はあまり得意ではないということ。 指示にされたことを直接的な目的と考えがちなAIに「動かないコードを動くように修正して」と依頼すると、彼らは動くようにすることに全力を注ぐ。原因究明して手を打つのではなく、とくかく症状緩和・対症療法的にその場しのぎの対応をとるらしい。「エラーを無理やりつぶす例外処理」のように単に臭いものに蓋をするだけの対応や「無意味な条件分岐」を繰り返し試すことも、局所最適な修正をtry and error的に繰り返した結果と言えます。

またAIは指示されない限り既存のコードを正しい前提で扱い、既存コードに対しる大きなコード修正をせず、付け足しつけたしで状況を改善しようとする傾向もあるようです。これもバウムクーヘン化する理由の一つといえるでしょう。

これだけみていると、ますます初心者プログラマーがやりがちな行動に思えてきました。。。

AIコーディングにおけるマネジメント

一方でやりたいこと・ロジックが明確になった仕様書をAIに渡して、それをもとに1からコーディングしてもらうことはAIが得意とする領域のようです。昨今いわれている仕様駆動開発というものがそれにあたるのかしら？ 実現したいことを、ロジックの詳細部分まで自然言語で落とし込んだ（疑似コードのような）仕様書をAIに渡すと、AIはかなり正確かつ早くコーディングしてくれます。 私も普段あまり触らないPowerShellで隙間埋めや作業効率化のバッチを作成する際によくこの手法を使っています。やりたいこと、ロジック（ここで分岐して、ここでこういう状態になるまでループして）は頭の中にあるけれど、それをPowerShellで実現しようとすると慣れていなくてお作法がわからん（if文の書き方、loopはfor？while？etc）。。。そんなケースでもやりたいことさえ見える化できれば、あとはAIがいい感じに対応してくれます。

そんな話を再びAI相手に壁打ちしていたら、また素敵な例え表現を提案してくれました。

AIは 「速くて従順なコーダー」にはなれる、でも「責任を負うSE」にはなれない

なるほど、納得ですね。前回のエントリにも書きましたが、結局はAIが何を得意とし何を苦手とするか理解した上で、AIが得意とすることはAIに任せ、AIが苦手とする部分は任せない、もしくはAIが理解できるレベル感に作業ブレイクした上で任せるというAIマネジメント力が重要なスキルになってくるなと改めて感じました。

もちろん最初にあげたような既存コードの修正についても、もっと具体的に何をどう直してほしいのか指示する、もしくはAIに調査を任せるにしても調査結果を踏まえて修正方針を何度かやりとりして正しい判断を人間がする、アクションをとっていれば結果は変わったかもしれません。そういった丁寧なアプローチを怠り、あたかも先輩プログラマーが書いたプログラムの修正を新人プログラマーに丸投げするような指示の出し方をしたがために、AIも新人プログラマー的な行動になり、いけてないバウムクーヘンコードを量産してしまったものと考えます。完全にマネジメント側の落ち度ですね。

とはいえ、常に詳細な仕様書を書いてAIに渡す、というのはなかなか辛いもの。要件・設計からから詳細な仕様書を起こす専属の担当者がいるのであればよいのですが、1人チームが多い私にとっては。。。 そうしたケースでも、比較的手軽、かつ有効にAIコーディングを活用できた例を次に示してみます。

AIコーディングが有効に感じた経験

※ あくまで一個人の体験をベースにした所感です。

小さな部品の開発

処理の目的が単一・シンプルなプログラムの開発であれば、AIの効果は抜群です。 例えば前述したようなちょっとしたバッチ処理。最近だとジョブスケジューラに組み込むファイル整理・移動を実現するPowerShellのバッチをAIに作ってもらいました。やることはシンプルでロジック構成も頭の中にある、でもPowerShellのお作法を調べながら自分で書くのはしんどい。そんな状況だったので、やりたいことを仕様書としてまとめたテキストをプロンプトとして渡したところ、一瞬でほしいものを作ってくれました。

プロトタイプ（捨てる前提のプログラム）

画面にイメージを目に見える形、動く形で作りたい、なんていうケースもAIには向いていると思います。画面仕様書を渡してあげれば一枚もののページであれば簡単にモックアップを作成してくれます。こうしたケースでは作成物の寿命は極めて短く、基本捨てる前提のコードになります。そのため多少汚く継ぎ接ぎだらけだったとしても大きな問題はありません。また、見直しが発生した場合もコードを修正させるよりも、再度見直し後の仕様で再生成させたほうが早く確実なケースが多いと思います。

設計書のリバース生成

AIにコーディングさせるのではなく、既存のコードからAIに設計書などのドキュメントをリバース生成させるというものかなり有用に感じています。後からドキュメント整備するのってめんどくさいですよね(笑)。そこをAIが担ってくれるわけです。OpenAPI（Swagger）の仕様書なんかも一瞬で作ってくれるので非常に助かっています。

まとめ

今回は、生成AIが万能なものではないことを、プログラムコードをぐちゃぐちゃにされた副作用から大いに思い知らされました。あらためてAIと仲良く、AIに助けられながら生きていく上では、AIの役割・得意不得意を理解して、与えるべきタスクを取捨選択・管理するマネジメントスキルが重要になってくることを痛感しました。でもこれってAIに限らずどんなツール、さらに言えば一緒に働く同僚との関係でも同じことがいえるのかもしれません。相手の役割や得意不得意を理解しないまま期待だけを押し付けてしまえば、思わぬすれ違いが起きて、その結果に頭を抱えたり、知らず知らずのうちに互いに傷つけてしまったりしがちです。

SFの世界で描かれるAIやロボットが人類に敵対する未来も、ひょっとしたらこうした小さな誤解・引っかかりが原因になりうるのかな、なんてふと思ったところで締めたいと思います。駄文にお付き合いいただきありがとうございました。