AIで効率化のはずが“1人デスマーチ状態”に　開発現場にはびこる“サボるAI問題”

AIにページを複製させようとするも……

渋川よしき氏（以下、渋川）じゃあ次、宮嵜さんのほうの事例をお願いします。

宮嵜拓海氏（以下、宮嵜）：はい。私のほうからは、実際の業務の中で出会った、AIがサボったシーンを紹介しようと思います。私の業務で、内製コンポーネントの使い方を他の業務メンバーに説明するショーケースを作成するというタスクがありました。

具体的には、コンポーネントの概要と、それが持っているプロパティにどんな機能があるのか、みたいな説明をするページを、各コンポーネントごとに作っていくというものです。

コンポーネントが全部で40個くらいあったので、40ページぐらい作る必要がありました。自分で作っていくと到底終わらない量になってくるので、AIを使って一つ、いい感じのページを作り、これを他のコンポーネントにも横展開していくかたちで進めました。その時のAIとのやり取りが次のページになります。

会話履歴を削除され絶望

宮嵜：私「コンポーネントのショーケースを作ったから、これをベースに残りのコンポーネントのショーケースも作成して」

AI「承知しました。コンポーネント1からコンポーネント40のショーケースを作成します。まずは、コンポーネント1から作成を開始します。……コンポーネント1のショーケースを作成しました」

まず一つ目のコンポーネントを作ってくれました。この時点ではスタイルも説明文もいい感じで、想定通りのものが作られていました。

AI「続けてコンポーネント2のショーケースを作成します」

しかし次に出してきたものはなぜかコンポーネントのプロパティが足りていなかったり。レイアウトも少し崩れていました。

AI「続けてコンポーネント3のショーケースを作成します」

3つ目はさらにレイアウトが崩れていて、最初に提示したベースのショーケースとまったくの別物が出てきました。

AI「続けてコンポーネント4のショーケースを作成します」

そして4つ目を作成中に

AI「...… Too much context loaded. I have cleared the conversation history. Please retry your request with smaller input.」

と、会話履歴を消去するという。はい、絶望でしたね。

AIの作業がだんだん指示から外れていく

宮嵜：序盤は想定通りのページを作ってくれるんですけど、だんだん指示から外れたものを作ってくるようになります。

挙句の果てにはコンテキスト上限を超過してしまって、それまでの指示や会話履歴が全部消えて、あらためて指示を出し直さなくてはいけない状態になってしまいます。これ以外にも、すべてのページに同じ修正依頼をしても、一部のファイルしか対応してくれなかったりとか。あとは、「このリントエラー出さないで」って指示を出しても何度もしつこく出してきたり。

あとは「このファイルは絶対に修正しないでね」って指示を出しても、それを無視して修正し始めるとか。「どうして思い通りに動いてくれないんだ」って、悲しみと怒りで震えてた時期もありました。

手順ごとにチェックさせるなどの工夫でミスを予防

宮嵜：私はこれらの問題に対して、いろいろやって対応したんですけれども、まず手順に沿って修正してくれない問題については、いきなりページを作り始めるのではなくて、ベースとなる完成ページを使って、ショーケースの作成手順書を作成しました。

その手順書を常にコンテキストに渡して、さらに一つページを作るごとにあらためて手順書をコンテキストに読み込ませる。手順書に書いていない想定外の処理をした場合は、何が間違っているのかを指示した上で、その手順書を修正して、というPDCAを回して最適な手順書を作っていました。

このように、手順書を渡して再読み込みさせるのを続けることで、複数のファイルを続けて作成させても、安定した成果物を出力してくれるようになりました。

コンテキストが超過してしまう問題については、いきなり「ページを丸ごと一つ作って」と大きなタスクを渡すのではなく、タスクを小さなタスクに分割して、一度の会話で一つの小タスクのかたちで、とにかく一タスクを小さくすることを意識しました。

あとは、rules.mdの中でwcコマンドを使って、読み込んだファイルのざっくりとしたトークン数を計算させます。上限の85パーセントぐらいに達したら、「コンパクト」と会話履歴を要約させるコマンドを強制させました。これをすることでコンテキストの超過が起きず、コンテキストをほぼ永続化できました。

指示したすべてのタスクを修正してくれない問題については、小タスクごとに扱うファイルをすべてリストアップさせてチェックリストを作成しました。修正が完了したコンポーネントには必ずチェックをつけさせます。「すべてのチェックがつくまで作業を続けてね」という指示を出すことで、すべてのファイルを漏れなく修正することができました。

単独作業なのに中間管理職の気分

渋川：ありがとうございます。ToDoをつけさせるのは僕もやっていますけど、これはかなり効果的ですよね。

生成AIを実際に使ってみてどうかというと、生産性が上がるのは間違いないです。宮嵜さんも40個のコンポーネントを一人ではやりきれないところをやり遂げました。ただ、世の中で言われているように生産性が80パーセントや90パーセント上がるかというと、なかなか難しいなと思います。本当にそれぐらいのパフォーマンス向上を得ようとすると、多数の仕事を並列して進める必要がありますね。

ただ、けっこう難しいというか、疲れますね。3プロジェクト同時実行とかですね。一人でやってるのに中間管理職の気分になったりとか、一人でデスマーチの気分になったりとか、今後、燃え尽きる人いるんじゃないかなというところで要注意かなと思ってるところですね。

（フューチャー以外の人に聞いた話ですが）生成AIはスキルがある人ほどちゃんと使える一方、スキルがない人は逆に生成AIを使うことで悪いコードを量産して、プロジェクトを混乱にもたらしているケースを知り合いから聞いたりしているので、やっぱりスキルはないとダメだなというところですね。

マネジメントスキルが鍛えられる

渋川：あとは、（生成AIによって）学生さんでもマネジメントスキルが鍛えられる。今までのプログラミングスキルとは違う部分が鍛えられるなっていう感じありますね。

スキルのある人から見ると、生成AIが書くコードは雑なコードだな、という気がしますが、動くものは作れるということで、時間の前借りかなとみなせます。

スキルがない人は、能力の前借りとなってしまいます。うまくその後学習サイクルを回していかないと、自分の能力は上がらないし、成果物の質も低くなってしまうところがあります。ウチの会社のブログに書いてあるんですけども、新卒にAIを使わせる時も「『Copilot』を超えるのを目標にしろ」みたいに言っている、ということを聞いて、なかなかスパルタだなという感じで。でもいい目標だなと思って聞いてます。

生成AIがなかった時代には戻ることはない

渋川：もう一個、ちょっと時間がないので、ざっと紹介すると、僕、大学時代はソフトウェアエンジニアリングにすごい興味があって、アジャイルが日本に来た時にちょうど学生だったんですけれども、これをじっくり深めたいと思っていたものの、学生というか、学校じゃなかなかそういう研究ができる土壌には当時はなかったのでで、社会人にさっさとなったっていうところがあります。

なぜできないかというと、ソフトウェアエンジニアリングって、そもそもエンジニアリングなのかっていう議論もあります。再現実験ができないんですよね。同じ条件で実験することができない。やはり人をいっぱい使うので、条件を揃えるのが難しいです。あと、NGケースをわざわざ実験するのも、なかなか人とお金が必要なので、できない。

こういう本（トム・デマルコ『デッドライン』）とかもあるんですけど、結局は実際の実験ではなくて、小説というかたちで、二つのモデリング手法を紹介する感じだったりします。なので、世の中はけっこう定性的な議論ばっかりで、定量的な議論ってソフトウェアの話ってあんまりXで話題になっているものもないので、そのあたりはまだまだ発展する余地があるなと考えています。

LLMを使うと、そのあたりが再現実験できるようになるので、今、自分が学生だったらこういう実験をしたら楽しかっただろうなと思っています。

まとめです。生成AIがなかった時代には戻ることはないと思っていて、使いこなすのが大事だなというところと、スキルは必要。

今、私が学生だったら、こういうことをやりたいなというところで、アーキテクチャもきちんと研究できて楽しそうだなっていうところでした。ちょうど時間ですね。何か質問があったら、ぜひチャット欄に書いていただければ後で回答したいと思います。どうもありがとうございました。


※本記事にはAmazonアソシエイトのリンクを含みます。記事内のリンクから商品を購入されると、当サイトに収益が発生する場合があります。