生成AIについて最近、考えていることを記録しておきます。 この記事は、2025年2月27日に書いた記事の続きです。あわせて読むとおもしろいかもしれません。
この記事のすべては2025年11月3日時点での個人の見解です。
自分の興味
生成AIの流行期しばらくは、「これまでの開発プロセスにどう活用するか」を中心に考えていました。たとえばDevinやClaude Codeをどう使うか、です。
ただ、最近はこのあたりへの興味は薄れてきています。理由は大きく二つあります。ひとつは、当たり前になりつつあって画期的な変化が起きにくいと感じていること。もうひとつは、上の記事を今読むとわかるように陳腐化のスピードが速いことです。加えて、DevinやClaude Codeのようなツールは自分でコントロールできる範囲が狭く、カスタマイズに時間をかけても「用意された舞台の上で踊っている」感じが拭えません。結果として、「生成AIを活用したツールをどう使うか」への関心は薄れました。
こうした背景と、現在、生成AIを活用したプロダクトの開発を行っていることもあり、今は「生成AIをプロダクトにどう組み込むか」に興味が移っています。
生成AIをプロダクトに組み込む
システムプロンプトは短くすべきでは？
プロダクトに生成AIを組み込むとき、まずはシステムプロンプトで振る舞いを定義します。短期的には、プロンプトの記述量を増やすほど狙った振る舞いに近づけられます。しかし、増やし過ぎると振る舞いの複雑性が上がり、管理が難しくなります。さらに、システムプロンプトに強く依存していると、モデルを変更した際に同じ挙動を再現できなくなるリスクが高いと感じています。
生成AI由来の複雑性を抑え、将来のモデル変更にも備えるために、システムプロンプトは可能な限り短く保つべきではないか、と考えています。
Tool callingの設計
システムプロンプト中心の定義には限界があり、出力の不安定さも避けられません。安定した振る舞いをプロダクトで実現するには、Tool callingの活用が不可欠だと思っています。
重要だと感じている点は次のとおりです。
- 分割単位：どの粒度でToolを切り出すか（副作用の有無や責務の境界をどう引くか）。
- Input/Outputスキーマ：入力・出力の型や制約、失敗時の表現をどう定義するか。
- 結果の扱い：Toolの出力をどのように検証・補正するか。
- 役割分担：どこまでを生成AIに任せ、どこからを決定的な処理に寄せるか。
要するに、「プロンプトで頑張る」のではなく、「Tool設計で挙動を固定化する」ことが、いま生成AIをプロダクトに組み込む上での要点だと考えています。
これから
他にも考えていることはありますが、この記事ではこのくらいにしておきます。
これからも、生成AIを活用したプロダクトを実際に使い、動向をウォッチし、そこで得た知見を自分自身が関わるプロダクトに取り入れていきたいです。どのように生成AIを使っているのか、なぜ機能変更が行われたのか、その背景を推測しながら観察していきます。
生成AIを使ったプロダクト開発には知識だけでは足りず、実際に作ってみて検証、改善の繰り返しが重要です。私は生成AIを使ったプロダクト開発におもしろさを感じますし、自分はそこが得意なのではないかと思っています。なので、そういう仕事をしていきたいし、今後も学び続けて変化に対応していきたいと思っています。
また、実際に生成AIをプロダクトに組み込んでみると、プロダクトごとにその方法を創造的に考える必要があると感じます。ある実装をコピペ的にプロダクトへそのまま適用することは、基本的にできないと考えています。また、そのような開発には自分はおもしろさを感じられません。プロダクトに合わせて設計することを、これからも大切にしたいです。
