AIテストは信用できる? AIテストの外堀の埋め方

こんにちは、横井です。

前回はAIコーディングに対する品質担保についてお話ししました。結論としては人がコーディングしようが、AIがコーディングしようが、設計通りに実装できているか? を確認するにはテストが必要。というごくごく当たり前の話でした。(笑)

もう一つは生成AIでもテストコードは生成可能という話です。しかし、そのテストコードがどれだけ信頼できるかは、作成方法や段取りに大きく依存する問題でもあります。

一般的な開発プロセスでは、まず設計を行い、次にアプリケーションコードを作成し、最後にテストコードを作成するという流れになります。しかし、その場合、テスト実行時にエラーが発生した際、問題がアプリケーションコードにあるのか、テストコードにあるのか判断が難しくなるという課題があります。これはAIコーディングに限らず、スクラッチでの開発においても同様の悩みとなります。つまり、アプリケーションコードの品質を担保するためにテストコードが必要となり、そのテストコードの品質を担保するためにさらにテストコードが求められる、いわゆる「テストコードの無限ループ」問題に突き当たります。

このような問題に対する解決策として、TDD（テスト駆動開発）の手法が提唱されています。TDDとは、アプリケーションコードを作成する前に、まずテストコード、すなわちテストケースを作成し、その状態で初めてアプリケーションコードを実装するという流れです。常にテストコードを実行し、テスト結果がグリーン（合格）の状態を維持することを重視する考え方です。

ただし、TDDのポイントは単にテストコードを先に作成することではなく、まずはテストケースを漏れなく洗い出すことにあります。そしてそのためには、十分な設計が不可欠です。設計が整っていなければ、網羅的なテストケースの洗い出しは難しくなります。つまり、TDDとは、テストコードを作成するためにテストケースを検討し、その検討のために設計をしっかり行うという、一連の決められたプロセスに基づいてワークフローを回すことが肝心なのです。

以上の話はスクラッチ開発での一般的な話ですが、実際にはこの方法論はAIコーディングにおいても十分に適用可能です。常にテスト結果を確認しながら開発を進めることで、生成AIの高速なコーディング能力と、求める品質の両立が実現できると考えます。

では。

---

すみません、追記です。

TDDを実践することでコードの品質を上げることができると書きましたが、この場合当然の事ながらテスト実行の回数が増えます。CLIベースのテストツールだと、テスト実行中のモニタリング情報を秒単位で出力します(画面でリフレッシュさせているような感じ)。結果として、例えばエラーが1つしか出なくても、テストが完了するまでのモニタ表示用の出力が延々と続き、結果としてLLMへの送信量が莫大になります。しかも、膨大なログを解析するの時間もかかり、結果一つしかエラーが無いとか、エラーがゼロとかだと、API呼び出しの待ち時間とコスト消費が馬鹿になりません。(あっという間にチャージしたクレジットが溶けていきます)

これはAIコーディングを品質良く実施する事の可否と、技術的コスト的問題は別物であるという事です。なので、私のブログを見たからといってすぐさまTDDに取り組むのであればそれなりのお金の消費を覚悟する必要があります。

では。

AIコーディングの品質はどう担保する？

こんにちは、横井です。

今回は、AIコーディングにおける品質担保についてです。以前の記事でも触れたように、LLM（大規模言語モデル）が学習済みのアーキテクチャやデザインパターン、アルゴリズムを活用すれば、人間が苦労して作業するよりも遥かに高速にコーディングが可能になります。しかしそれと、実際に要件や仕様を満たしたコードが得られているかどうかは、また別の問題です。

まず、LLMの種類によってもコーディングの品質は大きく異なります。私自身は(コーディングのさせ方にも影響されるのでしょうが)、Claude 3.5 Sonnet 一択です。最近リリースされ、評判の高いGemini 2.0 Proについては、私にはあまり合わない印象を受けました。いかにマネジメント方法でコーディングをコントロールできるように見えても、実際には要件を無視したコードや、途中で省略されたコードが生成され、期待外れとなるケースが多々ありました。無償なのでなんとか使いこなそうと試みるものの、金銭面では節約できても、結果として時間がかかり、満足度が低くなってしまうという現実もあります。

次に、仕様通りのコーディングが実現されているかどうかという点ですが、結局のところ、テストを行って確認するしかありません。幸い、現在では多様なテストツールが存在します。私も色々とテストコードをAIコーディングしてみましたが、実際に試してみると、ソースコードとテストコードの両方が作成された後、テスト実行でエラーが発生した際に、どちらに原因があるのか判断がつかなくなり、場合によってはテストコード自体を修正してしまうこともあるのです。こうなると、テストコードの実装が問題なのか、テストケースそのものが変わってしまっているのかが不明瞭となり、混乱を招きます。

また、以前にも書きましたが、テストエラー発生→エラー修正→テスト再実行→テストエラー発生と修正とエラーの無限ループも起きがちです。どうしても視野が局所的になり、局所的な修正になるので、あちらを直せばこちらがおかしくなる。みたいな事になってしまいます。

そこで、テスト実行後にいきなり修正を加えるのではなく、テスト結果をまずファイルに出力し、エラー(Test Fail)が発生した場合は原因と対応策もファイルに追記するテストレポートの作成を義務付けるなどのルールを設ける事で、いきなり修正→エラー頻発といった負の連鎖を防ぐ事ができます。

この様にコードを自動的に生成してくれるといっても、その品質を担保するためには色々な工夫が必要になってきます。

では。

全体を把握すること、全てを見通すこと

 

こんにちは、横井です。

AIコーディングを進めていると、あたかもAIがリポジトリ全体を見通して作業しているかのように錯覚することがあります。

実際にはAIはその都度のリクエストに対して応答しているだけです。LLM（大規模言語モデル）やエージェントのメモリ機能のおかげで、連続してリクエストを送ると、あたかも学習し成長しているかのような印象を抱いてしまいます。

しかし、例えばコードにエラーがあり修正を行うのですが、エラーが解消されない場合は再び修正を試みる。。といったコード修正の無限ループに陥った場合、一度作業を中断して状況を見直し再び作業を再開すると、これまでの経緯が反映されず、ルールに反した動作が現れることがあります。その結果、コードが破損し「最初から作り直した方が早いかな？」といった残念な感じになることもありました。

また、AIコーディングでは、依存関係の確認、すなわちクロスリファレンス機能が機能していない点も問題です。たとえば、GeneXusでは、オブジェクトや項目属性がどこで利用されているかがクロスリファレンスとして即座に把握できるため、使用されているものは削除できない安全策が整っています。しかし、スクラッチ開発におけるソースコードの管理では、GitHubのようなリポジトリでも依存関係が完全には把握されず、「問題ない」と判断して削除したファイルが、実は他の部分から参照され、システムが正常に動作しなくなるといった事態が起こりやすいです。まあ、これはAIコーディングに限った話ではありませんが、GeneXus開発に慣れているとクロスリファレンス機能が存在するのが当たり前だったので結構困りました。

別な話としては、アジャイルにAIコーディングを進めると、機能を追加してくなかでリファクタリングを提案してくるのですが、あたかも全てを見直してコード修正してくれているようで実はメモリに残っている範囲でリファクタリングを行い、随分と初期に行ったコーディング個所が漏れ落ちてしまう事もあります。

例えばデータベースアクセスのコードが、効率向上を考慮してコネクションプールを利用するようにリファクタしてくれるのですが、初期のコーディング部分は直接接続のまま残されてしまっていたり。といった具合です。

このように人は広い視野で物事(リポジトリ内)を記憶しておくことができるので「ここ大丈夫だったかな?」と目くばせする事ができます。(もちろん、業務システムの様に量が多く、漏れ抜けが許されない場合は横展開チェックなど記憶に頼らない確認手段は必要ですが)

一方でLLMはリポジトリ全体を記憶しておくこと、記憶し続ける事が現状では難しいので、その都度のリクエストに含まれる情報や短期的なメモリ機能の範囲でしか「把握」という状況ができません。

なんらか代替手段が無いと業務システムのような規模は難しいなと感じています。

私がAIコーディングにおいてリポジトリ管理として望む点は、以下になります。

• クロスリファレンス機能
• 例えば、グラフデータベースのように各ソースコード間の関係性を表現できる仕組みがあれば、どの部分に依存しているかが一目で分かり、誤って必要なファイルを削除してしまうといったリスクを減らすことができます。
• リポジトリ(ソースコード)全体の把握
• こちらは、リポジトリ全体を文脈で検索可能なデータベース化ができれば。と思います。現状のRAG（Retrieval Augmented Generation）で実現できるかは不明な部分もあります。ソースコードのファイルは大きいため、通常RAG化する場合はファイルを複数のチャンクに分割してベクトル化します。ひとつのチャンク内に収まる文脈であれば、文脈検索により正確な抽出が可能です。しかし、ロジックが分割されたチャンクに跨った状態だと、文脈が分断され検索精度が出ない(ヒットしない)可能性もあります。逆に、ソースコード全体を丸ごとベクトル計算してしまうと、文脈が広がりすぎてベクトルの意味が希薄になってしまいます。そのため、適切な文脈情報を保持するには、チャンク分割は避けられませんがその要求は矛盾したものとなってしまいます。ただ単に機械的に分割するのではなく、ロジックの処理単位に分割できれば、チャンク単位での検索でも高い正確性が持てるかもしれません。ただ、この場合はどうやって分割するか? コードのロジックを解釈しながら分割ができるのか? といった技術課題が多々あり実現可能かどうかは未知数ですが、今後の技術の進展に期待したいところです。

といった感じで、全体を把握する・全てを見通す。という人にはごく当たり前にできる事が実は結構難解で高度な機能なのだとAIを使い込んでみて気づかされました。

では。

AIコーディングはアジャイル向き？ウォーターフォール向き？

こんにちは、横井です。

先日の投稿では、AIコーディングの品質向上のためには、適切なプロセス定義が重要であると述べました。そこで、プロセスを定義する＝ウォーターフォールという表現を用いましたが、これは必ずしも「AIコーディングはウォーターフォール向き」という意味ではありません。では逆に、AIコーディングはアジャイル向きなのでしょうか?

どのようなプロセスがAIコーディングに適しているのか考えてみましょう。

まず、プロセスを明確に定義するという観点では、それぞれのプロセスに対するインプットとアウトプットを明確にする。作業計画を策定し、その計画をさらに具体的なタスクに落とし込む。といった事が重要です。たとえば、コーディング前にドキュメントをレビューする。修正作業に入る前には各修正箇所をピックアップし修正理由や内容をドキュメント化する。といった手順が考えられます。一見すると、これはウォーターフォールモデルのような厳格なプロセスに見えます。

しかし、実際のところ、段取り的にはウォーターフォールに近いものの、AIコーディングは複数人での開発や、各工程を別々の担当者が分担する従来の開発体制とは異なります。(もちろん、今後はマルチエージェントへと機能が進化すると思うので、役割ごとのエージェントとか、コーディング自体も複数のエージェントで分担する。とか組織的なエージェントになる可能性はあります)　 また、業務システムのようにたくさんの機能を持つシステムを開発する場合、一度に全ての設計書やドキュメント、機能をまとめて実装するのは、今時点でのAIコーディングには適していません。

大規模な機能を実装する場合は、まずスコープ(一回のコーディング対象)を小さく区切り、その単位ごとに設計、計画、コーディング、テストというサイクルを回す必要があります。これは、アジャイルやスクラムにおけるイテレーションやスプリントに近い作業単位の感覚と言えるでしょう。つまり、プロセスの段取り自体はウォーターフォール的に定義しながらも、実際のドキュメント作成やコーディングは、ひとつの大規模なチームではなく、小単位に分かれてサイクリックに進める流れとなります。

人が実施する従来のアジャイル開発との大きな違いは、ドキュメンテーションやコーディングのスピードにあります。通常、2週間から3週間で一サイクルを回すところを、AIコーディングではそのサイクルを1日で完了できる場合もあります。現在はAPIのトークン数やリクエスト回数の制限があるため、すべてが高速に進むわけではありませんが(大抵は最初は凄いスピードでコーディングしていきますが、途中からAPIのリクエスト待ちが発生しコーディング時間より待ち時間の方が長くなります)、基本的には非常に迅速なサイクルでの開発が可能となっています。

このように、AIコーディングに最適なプロセスとは、単純にウォーターフォールかアジャイルかという二元論ではなく、ウォーターフォール的なプロセス定義と、アジャイル的なサイクル回しのハイブリッドであると考えられます。

では。

 

AIの賢い使い方、エージェントとして使う方法

こんにちは。横井です。

今回は、LLM（大規模言語モデル）やエージェントをどのように活用すればよいのか、その基本的な考え方を書いてみたいと思います。

まず最初に大切なのは、何をアウトプットとして求めているのか? という作業のゴールを明確にすることです。当然これは人が指示する事になります。このゴールの定義が曖昧だとアウトプットも想定したものと違ったものになってしまいがちです。

次にどのようゴールを達成するか──いわゆる「How」の部分は、LLMに考えさせるのがポイントだと思います。色々試してみた経験として人が一から十までHowの部分を指定すると、その指定から漏れた物の挙動が不安定になり思ったアウトプットになりませんでした。

ただし、この「How」の部分には方法論やプロセスといった進め方の方針が必要です。ここに関してはそれらをあらかじめルールとして定義し、前提として伝えておく必要があります。つまり方針は人が指示をし、その方針に則ってLLMがHowを考える。という分担になります。

たとえば(コーディング作業で例えると)、

• コーディングする前に必ずドキュメントを書いておく
• コーディング前にやるべきことをリストアップしておく
• アプリケーションコードとテストコードをセットで書く
• テストコードを先に書く

といった手順や方針です。これらはある意味、「ウォーターフォール型」のように、プロセスの進め方を先に定めてしまうこととも言えます。こうした方法論や方向性を設定したうえで、アーキテクチャや要件、そして実装したい機能をもとに「具体的にどう作るか」というステップをLLMに考えさせるのです。

次に、作業計画についてです。これはHowの部分をさらに具体的な作業レベルのタスクにブレイクダウンし、詳細化させる事です。これもLLMに任せた方がよいです。タスクを細かく分解してもらうことで、「何をいつ、どの順序で行うか」を明確化できますし、その進捗を管理するToDoとしても活用できます。LLM自身が考える事で、ゴールへ向かう道を見失わずに、一直線で進むことが可能になります。

以上のように考えると、人が考えて指示すべきことと、LLMが考えたり作業したりすべきことを明確に定義・分担することが重要だといえます。具体的に言えば、人間が考えるべきことは主に以下の二点です。

1. ゴールの定義
2. LLMに仕事を考えさせたり、実行させるための方法論やプロセスの方向付け

一方、ゴールを達成するための具体的なステップやタスクのブレイクダウン、作業順序、ドキュメント出力などについては、LLMに考えさせた方が良いです。そして、人はLLMが出してきた実現手段や実行計画、To Doリストなどをレビューするという役割を担います。

エージェント機能を使う場合は、たとえばシステムプロンプトやカスタムインストラクション、ルール設定などにおいて、どのレイヤーで何を定義するかを整理し、指示の重複や矛盾を起こさないようにすることが肝心です。

こうした工夫をこらせば、自動的・自律的にLLMやエージェントに作業を進めてもらうことも十分に可能になるのではないでしょうか。繰り返しになりますが大切なのは、「人が定めるべき前提や方針」と「LLMに委ねるべき具体的な実行手段や計画」の切り分けを明確にし、お互いの役割をはっきりさせることだと感じています。

では。

AIコーディングはプログラマの終わりの始まりか？

 こんにちは。横井です。

AIコーディングに関する記事の4回目となる今回は、ややショッキングなタイトルかもしれません。これまでさまざまなAIコーディングを試してきましたが、その経験の中で感じたことを書きたいと思います。

AIに仕事を任せる場合、大きな課題となるのはアウトプットの精度と再現性、すなわち何度実行しても同じ結果が得られるかという点です。この二点を考えると、まだ仕事を安心して任せられる段階ではないと考える方も多いでしょう。では、AIコーディングという観点ではどうでしょうか。ここまで取り組む中で、私自身が少し驚いた事例がありますので、いくつか紹介します。

まず一つ目は、APIなどのインターフェースを呼び出すロジックに関することです。APIに対してはインターフェース仕様が公開されていれば、AIはその使い方を認識できるため、要件──つまりどのような機能を実装したいか──を伝えるだけで、具体的なコーディング指示をしなくとも、それに合わせたコードを書いてくれます。

少し昔話になりますが、2000年前後に「Webサービス」という言葉が登場した頃、技術に詳しくないマーケティング系の人が「Webサービスを使えば自由に自動的に呼べるようになるよね」と言っていたことがありました。当時、現場のエンジニアだった私には「いやいや、そんなのは無理でしょう。結局は人がロジックをコーディングする必要があるのだから、自動でできるわけがない」としか思えなかったのです。しかし、それから約25年を経て、生成AIの能力を目にすると、当時は夢物語のように感じられたことが、いまや現実化しているのだと実感しています。

今回私が作成したアプリは、実はLINEのボットアプリです。具体的には、ユーザーがボットに質問すると、ボットアプリがFAQデータをもとにLLMへ最適な回答を生成するよう依頼するという仕様になります。APIという観点では、LINEメッセージAPIの使用方法とLLMのAPIの使用方法、この二つがポイントでした。私自身、どちらの知識も経験もなかったにもかかわらず、実現したい内容をAIに伝えるだけで、その後の設計やコーディングはAIが行ってくれました。やりたいことを具体的なゴールとして設定するだけで、実際のコーディングはすべて任せることができたのです。

LLMベースのFAQ応答ボット 設計ドキュメント

もう一つ興味深かったのは、アーキテクチャやデザインパターンなど、システムやプログラミングにおける標準的な技術知識も、LLMがすでに学習しているのであれば、人が一から調べて試行錯誤する必要がないという点でした。具体例を挙げると、最初のバージョンではアプリが問い合わせを行うLLMはOpenAIのみ固定で使用していました。それを機能拡張として、Google Geminiも使えるようにしたい。さらに、環境変数によってどちらを使うか動的に切り替えられるようにしたい、という要件をAIに伝えたところ、インターフェースの継承やファクトリパターンを活用する設計を提案してきたのです。継承のクラス図やシーケンス図といったドキュメントまでもアウトプットしてくれましたので、私はそれをレビューし、要件どおりかどうか確認したうえでコーディングを依頼しました。その結果、LLMをパラメーターにより動的に切り替えられる、汎用性の高いアプリが出来ました。

LLMプロバイダーアーキテクチャ設計

このように、すでに学習されている技術的な知識の広さや深さは、私個人の情報量や経験値をはるかに超えています。こうした分野では、人間が時間をかけて自力でコーディングを行うこと自体に、もはや大きな価値を見いだしにくくなりつつあるのかもしれません。もちろん、学ぶことや経験を積むこと自体はかけがえのない大切な行為であり、私自身もそれを否定する気はまったくありません。ただし、仕事としてアウトプットを素早く正確に出すという観点においては、もはやAIには太刀打ちできないのではないかと感じてしまいました。

もっとも、私たちが扱っている業務システムは、以前にも述べたとおり、LLMが学習していない情報が多く含まれています。業界特有の商習慣や企業モデル（企業情報やビジネスモデル、業務内容）、そしてそれを支える組織形態などをLLMへインプットするのは現時点では難しい面があります。そのため、業務ロジックをAIに完全にコーディングさせるのはまだ難しいというのが実情です。しかし、これはあくまでも現時点での話にすぎません。業務知識を事前学習以外の形でLLMに渡す方法が確立され、実現したい業務内容を正しく伝えられるようになれば、将来的には業務ロジックのコーディングさえもAIでまかなえる可能性があるのではないか、と感じています。

では。

AIと人の違い

 こんにちは。横井です。これまで二回にわたって生成AIについての記事を書いてきましたが、今回は、作業を指示する立場から見て「AIと人の違い」についてお話ししようと思います。

まず、生成AIが現時点で「使える」と感じる方もいれば「まだ使えない」と感じる方もおり、その感想は人によって異なるようです。もちろん、どんな仕事を対象にするかや、どのような内容を依頼するかによっても変わってきます。私自身、ChatGPTが登場してからさまざまに試してきましたが、最近のAIコーディングに関して言うと、生成AIをうまく使うためのコツは主に次のように整理できるのではないかと思います。

1. やること（ゴール）とやらないことを明確にする
   いわゆる仕事のスコープをはっきりさせることです。

2. ゴールに向かう詳細なステップと順序を決める
   これは、指示する側が具体的に定義するか、あるいはAIに考えさせるのかによってやり方が変わってきます。

3. 前提条件や制約条件など、ゴール達成のための条件を定義する
   これらをきちんと定義しておくことで、AIの回答精度や作業の方向性が大きく変わります。

4. 作業と進捗をどの単位で確認するかを決める
   何を、どのタイミングで、どのようにチェックするのかを伝えれば、生成AIでも確実にアウトプットを出しやすくなります。以前の記事でご紹介したAIコーディングの成果を思い返していただくと、イメージしやすいかもしれません。

参考までに先の投稿でAIコーディングをさせたプロンプトは以下になります。(たくさんあるフェーズの中の一例です)

次のステップに入ります。 フェーズ6.2です。 
要件は 
1.LLMのAPI呼び出し時のリクエストデータとレスポンスデータを格納するDBを作成。テーブル名はprompt_history。 
項目は user_id、timestamp、request_type、request、responseです。主キーはuser_id、timestamp。request_typeは問合せ、ハルシネーションチェックの区分値です。 
2.LLMのAPI呼び出し時、具体的にはレスポンスを受領後にrequestデータとresponseデータをprompt_historyにinsertする。タイミングは
- 問合せ
- ハルシネーションチェック
の2つ。 
3.制約事項
- 既存の機能、ロジックは変更しない。意図は機能のデグレードはしない。特にコード修正する場合は他機能への影響がないか細心の注意をはかる。 
以上の要件を元にphase6.2の設計書をマークダウン形式のテキストファイルとして出力してください。
コーディング可能な詳細なレベルにブレイクダウンして検討してください。
必ず必ず必ず必ず必ず必ず必ず必ず必ず必ず必ず全部処理してください。まだコーディングはしないでください。

設計書をレビューしました。内容OKです。
では、続いて設計書の内容を元にtodoリストをマークダウン形式のテキストファイルとして出力してください。
コーディングが可能な詳細レベルのタスクに分割してください。タスクはマークダウン形式のtodoとして、チェックマークを付けられるようにして下さい。
必ず必ず必ず必ず必ず必ず必ず必ず必ず必ず全部処理してください。まだコーディングはしないで下さい。

TODOリストを確認しました。内容OKです。
では、コーディングに入りましょう。todoリストの順番にコーディングをして下さい。
コーディングする場合は、1.作業内容の確認、2.コーディング、3.結果のチェックまたはテストコードの実行、4.作業を終えた場合はtodoリストの該当タスクをチェックマークon。
以上をサイクルとして、todoリストのステップ単位で作業を進めてください。
必ず必ず必ず必ず必ず必ず必ず必ず全部処理してください。

このようにポイントを押さると、AIは思ったような結果を出力してくれます。

裏を返すと「生成AIが使えない」と感じるシーンでは、よく次のようなことが起こっています。

• 途中までしか作業をしない、あるいは途中で終わってしまう
• 本来やるべき手順を省略してしまう
• 間違いを修正する際に、今までの内容を全て消して再出力をしてしまう
• うまくいかない場合に修正とテストを繰り返し、エラーが出るたびに無限ループに陥ってしまう

こういった事を経験する事で生成AIが「実用的ではない」と思ってしまうのではないでしょうか。そんな方は是非、AI対する指示の出し方を変えてみてください。プロンプトエンジニアリングであるような小難しい文法や表記法などしなくてもいいです。私はほとんど音声入力で済ませていますし、文脈が通じれば問題ないです。

もっとも、こうした点を踏まえてみると、作業指示や管理の視点では、人が作業する場合とAIが作業する場合の本質的な違いはそれほどないと考えています。新人社員に対してどう指示し、どのように管理すれば期待するアウトプットが得られるか──そのやり方と、生成AIへの指示や管理のやり方は、じつはほぼ同じなのではないでしょうか。

もちろん、人であれば経験値が上がってくると、1を伝えるだけで10を理解できるようになることもありますが、勘違いや思い込みでミスが起こる可能性はゼロにはなりません。

いかに正しく目的を示し、条件を定め、進捗を管理するかが、AIであれ人であれ仕事をしてもらう重要なポイントだと言えるでしょう。

では。