AIとの効果的な対話：背景とスコープの理解
こんにちは、AI駆動開発部の日常へようこそ。 このポッドキャストは、日々AI駆動開発を行う企業家の山本とエンジニアの安倍が、AI駆動開発のリアルを緩く語り合う番組です。
はい、じゃあよろしくお願いします。
はい、よろしくお願いします。
はい、じゃあ今日は安倍ちゃんがAIにどういうふうに指示を出せば、いい感じにAIが動いてくれるかっていうのを話したいということなんで、ちょっとその話ができればなというふうに思っております。
どうしようかな。
じゃあお互いなんかどういう考え大事にしてるみたいな話をし合って、ディスカッションするみたいな感じでいい?
はい。
大丈夫ですかね。はい、じゃあこんな感じでいきましょう。
じゃあ僕からいきましょうかね。
僕は最近スキルでね、ちょうどエージェント向けのプロンプトを作成するスキルみたいなのを作ったんですけど、結構いろいろAIから質問が来たりとかするときに、割と大事にしてることは、それの背後にある背景みたいなのをきっちりと伝えると。
例えば、こういうことをやめてほしい、こういうことをやってほしい、こういうことを意識してほしいみたいな具体的な話を書く。
それを全部網羅しないといけないのかみたいな、いろいろなケースを網羅しないといけないのかみたいなことになってくると思うんですけれども、そうしたときにこういうのはやめてほしい、こういうのはやってほしいみたいなことを書いて、
これはあくまで一例だということを伝えて、この背後にある背景としてはこういう考え方にのっとって考えたものであるみたいなので、一個全部を一つの考え方でその具体で出したものを横串で刺すみたいなことをしてあげると、
なんかAI側も割とちゃんと理解してくれる。それを逆にしないと、世間ではこう言われてるからこれはアンチパターンだとか、そういうことを言われたりするよね、やっぱり。
なので、そこの裏側にある背景を含めてしっかりと伝えるという、例えば僕だったら、エージェントのモデルが進化すればするほど良くなるっていう余白を出しておきたいっていうのを前提としてあって、
結局きつく縛りすぎていると、モデルが進化すると逆に縛っていくから、そのモデル自体のポテンシャルを抑制するみたいな方向に振ることになると思うんですよね、そうするとモデルがアップデートするたびにメンテナンスをしていかないといけないみたいな感じになっちゃうって言って、
なのでそれは手間だから、AIエージェントにAI向けのプロンプトを考えさせると、基本的に安全側に倒そうとするよね、よりきつい縛りをとか、プログラムで縛ろうとか場合によってはみたいなのがあって、
それを避けるためにその今の考え、前提としてモデルがより良くなっていくって言った時に縛りすぎてたら可能性を殺しちゃうよねと、だから自然とAIのサービス自体、サービスとか仕組み自体がAIのモデルが頭が良くなれば良くなるほど勝手に頭が良くなっていくよねみたいな前提を持って、
その仕組みであったりプロンプトを考えて欲しいみたいなことを一個入れると、もうそのやって欲しくないことは全部やらないでくれるみたいな状態になるから、このメタ的な一個上の概念としてやるみたいな伝えるようにするっていうのが、
これだけどスキルとかに落とし込むことが多いけど、毎回毎回そこまでやったりはしないけど、まだしなんか一発では出てこない、何回か問答してその結果AIにどうしても伝わらない部分がやっぱり出てきて、これなんで伝わらないんだっけって考えた時に、
もう一個背景みたいなのを話すっていうのがまず一個、もう一つだけあってあと気付けてることというか、これも似てるっちゃ似てるんだけど、AIにやり取りを問答してる時の話かな、プロンプト一発ドーンっていうことは基本的にないと思っていて、
問答してる時に認識のそこがあるかどうかみたいなのを、なんかAIが今どのスコープでものを見てるのかみたいなのは意識するようにしてる。
ああ、それ確かにあるわ。
そう、例えば最近で言うとその組織、マルチテナントのSaaSの仕組みをちょっと想像してみてもらいたいんですけど、マルチテナントのSaaSの仕組みでテナントごとにしか情報が取れないのに、
テナントを切り替えてもそのセッションが引き継がれてるのはおかしいよねっていう問題提起を仮にしたとするじゃないですか、そうした時にAIはスコープとしてはどっちかに偏ると思っていて、
そもそも取れない方がおかしいよねみたいな話と、テナントをまたいで情報取得できた方がいいはずなのに取れないのがおかしいよねっていう話と、あとはテナントでその分離しているのにもかかわらず両方ともにセッションが露出しちゃってるみたいな、
とかおかしいよねみたいな話のどっちかに捉えると思うことが多いと、まあ大体そうだけど、でやり取りしていく中でAI自体はその露出したってる方が悪いっていうふうに思い込んじゃってるので、それを抑制する方向に行こうとすると、
けどそうした時に、このAIは今こいつはこっちのスコープで話してるんだなって思った時に、いやそもそも待てよと、そもそも前提として取れるべきものが取れてないことの方がおかしいんじゃないみたいな話を差し込めるかどうかみたいなのが、
なんかAIが最終的に自分の思ってる方向と同じ方向に着地させれるかどうかの割と要になることが割と多くて、なのでなんかどういう感性にのっとってAIが動いちゃっていってるのかっていうのを常に意識するみたいなのは結構大事かなっていうので、この2つが結構僕の中では強く意識してることって感じですね。
指示の出し方：具体例の活用と例を挙げないアプローチ
確かに今そのAIが認識していることを多分説明とかさせることによってずれてないかっていうのを多分検知しながらやっていくとかだと思うんだけど、僕も結構デザインを組んでもらってる時にやってることで、
なんか単純にこういう風な画面設計にしてほしいとかって伝えてわかりましたって言われたとしても、AIがどこに対して認識していてどうなるべきかみたいなのを描けてるかどうかは僕らの方もわからないっていうのがあって、
こうなってくると画面上にどこに問題があってどうしたいかどうするべきかっていうのを説明させることによって、僕もそれを認識できるし、AIもそこに思考を一旦ロックできるというか、ゴールを決めることができると思ってて、出力をさせることによってより強くゴールを決めることができるようになると思っているので、
割とそういうふうに説明させた上で、もし間違ってたんだったら、そもそも会話のターンを戻ってやり直したりとかするし、合ってるんだったらその出力された言葉をそのまま実装として落とし込んでもらうっていうのをやってきたりして、ちょっと似てるかなとは思ってるんだけど、そういうことはやっぱり。
あとね、さっき最初の方に言ってた、いくつか例を挙げたときに、そこに固定化されてそれをすべて網羅し落としてしまうので、これはあくまで例ですみたいな話を伝えるっていうふうに言ってたじゃないですか。
僕がやるときに同じようなことを僕もしてて、これはあくまで例ですよっていうこともあるし、逆に例を挙げないっていうのをたまにやったりしていて、例を言うとそこに思考がアジャストされるっていうのがすごく強くあって、もっと思考を狭めてほしくないというか、広く考えてほしいときとかは特にどうなんだろうな、
ちょっと上手い例が思い浮かばないけど、理想のこうあってほしいなみたいなのを掲げるだけ掲げて、その中身の細かいことについては一切触れないで考えてもらって、そういうのもちょっとやったりしますね、似てることで。
理想の背景にある経緯があるから、どのレイヤーに行こうが、それはあくまでも具体でしかないという感覚があるんですよね。
なので必ずやってほしいことがどの流度であれ、割とその背景は伝えるっていうのがマストかなっていうふうに思ってて、だから具体を伝えないってなったとしても、その抽象度の高いものに至った背景は伝えるべきで、そこが考えになるから、
だからどこまで抽象度を上げても、さらなる抽象化っていうのは存在すると思っていて、結局的には何も言わないみたいな、いい感じにしてぐらいしか言えなくなっちゃうから、意外と全てにおいて言えることかなっていうふうに。
まあいい感じに仮に一緒にいてって言っても、自分がいい感じに言ってる背景はっていうことを言い出すと、結局その背景は伝わる。
はいはい、まあ確かに。
なので、フックは与えるけど固定化しすぎないみたいな取り組みは結構必要ですよね。
まあそうだな、これで言うとさっき言ってたフックを与えるとちょっと似てるのかなとも思うんだけど、僕がよく意識していることは、結構先回りして考えて、
AIにこういうふうに指示を与えた結果、AIがどういうふうに思考を巡らせて、どんな回答を出してきそうかみたいなのを結構意識するように最近はなっていて、
普段自分が単純に思っていることを語る場合は絶対言わないようなことをあえてAIに指示することで、それがフックみたいな形で誘導する。
遠回しに誘導して、AIから求めている回答がどうやったら引き出されるのかなみたいなのをすごい意識して考えるように、指示を与えるようになったかなと思っています。
例えばなんですけど、これはよくあることだと思うんですけど、指摘をAIにしたときって、「すいませんでした。」とか、「こういう考えが甘かったです。」みたいな話に陥ってしまったりとかっていうのもよくあったりすると思うんですけど、
単純に謝ってほしいわけではない。これは結構最初の頃にも質問用のプロンプトを作った時の話を、AI駆動開発部の日常のラジオの最初の方のエピソードで話したりもしてたと思うんですけど、
質問とかしたときに求めているのは謝罪じゃないのに、結構謝罪してきたりする癖が当時AIとかにあったりして、それを回避するために、「あえて謝罪は求めていません。」みたいなことを当時は直接的に指示していたりとかしていたと思うんですけど、
どっちかっていうと最近はそのまんま指摘を指摘として与えるのではなくて、フックみたいなところが結構僕も近いのかなというか、似てるかなというふうに感じているところがあるんだけど、
僕はプロンプト、AIに指示を与える時に結構気にしているのが、AIがその発言によって結構僕の指示によって誘導されやすい傾向が当然ある、指示に追従してしまうっていう癖が強いかなというふうに思っているからこそなんですけど、
結構その指示を与えた結果、AIがどう感じて、何を認識して、結果的にどういうふうに回答を返すかっていうところを強く意識して、プロンプトは書くように、指示は書くようにしていて、
例えば、やっぱりこういう懸念があると思うんですけどどうですかみたいな話をすると、やっぱりその懸念についてはまず正当化することを先行して考えてしまって、まあ妥当ですよみたいな回答が返ってくることが多くて、
でもそれって僕からしてみれば本当に懸念があるのか、実は懸念としてもほとんどないものなのかみたいなのを一緒に議論したかったりすることがするので、どっちかっていうと、懸念はありますかみたいな質問をするというよりかは、
今この状況において、あなたの中でより良くするためにはどう考えたりしますかみたいな、もうちょっとその発言に誘導されないように、ワードをあえて伝えずに、もう少し広げて考えてもらえるような指示を与えたりとか、
あとはまあ今なんでそういう質問しているかというと、こういう背景がこういう風なところを理想としているからですみたいなことを伝えたりすることで、本来は懸念を聞きたいんだけどそこにはフックされない、フックされないようにする時もあるし、あえてフックさせるように指示を与えたりとかっていうのを結構気にしながら話したりしてますね。
セッション管理とメンタルモデルの切り替え
ああなるほど、それで言うと多分なんかその時、そのタイミングの時は、あれだね、どっちかで言うとその別セッションにそのセッションを読み込ませて、新しいやつにフラットに分析してくださいっていう、もうそのセッション自体にすでに思考性がついちゃって、
うんうん。
あとは前提がちょっとここ食い違ってますよねみたいな指摘とかを多分結構繰り返ししたりする時もあるからかな、なんか。
そうセッション、同一セッション上、俺ちょっとずれたな、別セッションに切り替えるから、なんかそう、そういうのもあるかもしれないですね。
うんうんうんうん。でも結局あれかな、セッション切り替える時っていうのは、まあその過去のセッションを見てもらったりして。
そうそうそうそうそう。この人がこういう分析してるんですけど、それに対してフラットに分析してくださいみたいな。で、えーと、自分がまあおかしいと思ってる部分がその時って必ず存在してるわけじゃん一応。
うんうんうん。
より良くって思ってるってことは何か不満に思ってるっていう状況ではあると思うから、なんでまあこの辺とかこういうところとかも含めて、なんかもうちょっとフラットに大きくなんか全体を俯瞰してみてくださいみたいな感じで言うと、
そう、その新しいセッション化すると他人だからもうなんか、その自己責任とかそんな話じゃなくて、一番本質的な回に至りやすいみたいなね、そういう。
確かに。なんかその思考がロックされてるかどうかみたいな、そのセッションの中で会話が、会話の積み重ねで思考がロックしたりするっていう話以前に、なんかAI自身も自分が喋ってるから、間違ってたかもしれないみたいなところを、
うんうん。
ベンチマーク上そうだと思うよね。ベンチマークを良くしようとしたら、やっぱこう、合ってることが重要なわけで、多分自分がやったことに対して。そう考えると、合ってる方向、なんか自分がやったことが合ってる方向に行くっていう、なんかある程度こう重み付けみたいなのをされてるはずで、多分内部的には。
うんうんうん。
まあ人も一緒だけど結局、バイアスというか自分の、自分の性格が合ってると思い込みたくなるっていうのはあんま変わんないと思うけど、まあ多分そういうのが多分裏側では効いてるだろうなーみたいな感じがあって。
まあちょっとプロンプトというかそのメッセージやり取りの仕方的なあれとはちょっとずれるかもしれないけど、終わり切って別セッション立てるみたいなことはよくするな。なんかちょっとでもそういう文脈が転換しそうなタイミングは絶対に別セッションにしてるね。
ああ。だからね、僕が動かしてる時のセッションの並列の数と山ちゃんが動かしてる時のセッションの並列の数というか、一緒に同時に立ち上がってるセッションの数では倍ぐらい違うなって感じてた。
うんうん。
なんかそういうのも結構あるのかもね。僕は結構…
ああそういうのはあるかもね。
根本的に間違ってそうだなとかっていうのが起きないとあんまり切り替えるところまでいかない。あとはまあ、AIもたまにはずれっぽいモデルを引いたりする時がある感覚があって、もう初手から全然トンチンカンに行っちゃったっていう時とかはもうもちろん変えたりするんだけど。
そうだからなんかその多分くじ引き的なところもなんか多分俺のところ認識では、自分がそうあって欲しかった認知モデルとその自分の指示によってそのAIがこう振る舞おうとしたみたいな認知モデルとか、その自分のこう探索する知識のスコープとかが、なんかこっちの指示としてなんかミスった方向に引きやすい指示の仕方してたんだなみたいな感じに近くて。
だからなんかその文脈とかが変わるタイミングって、なんかメンタルモデルごと変えないといけないことも結構あると思っていて。
なんか前話した、開発者がよく起きるシステムを考える時のモデルとかそういうのの考え方とかそういう時に考えるメンタルモデル的なこうマインドセットみたいなのと、
それをUIに表出させる時に、逆方向からユーザー視点で見た時のモデルっていうのは直感的に自分がしたい方向性から認知していくモデルと、開発者がシステムを開発するDBとかから考えるその逆伝パン的に考えていかないといけないから、
っていうのはメンタルモデル的に切り替えないといけないタイミングがどっかのタイミングであって、だからそこは多分ある程度UIとかUX考える人とシステム開発者っていうのはフェーズを切り分けないといけないっていう前提としてあると思うんですけど、
なんかそういうのがすごい細かくいろんな、それは今のはすごい分かりやすくシステムを組む時とUI UXを考える時は、もちろんその表出させないといけないモデルが絶対に違うわけだから、
それを多分なんかその、例えば開発者がそのシステム的な思考のままバーってボトムアップで作り上がっていくと、多分UXが全然考えられてないよねみたいなものになっちゃったりとかみたいなのがよく見る多分事象だと思うんですよね。
これをどっかで1日置いてメンタルモデル切り替えて、今日はUX考えようってしたら多分そうじゃなくなるはずだと思ってて、なんかそういう感覚で結構切り替えてるって感じなのかな。
まあ確かに。
フェーズごとのセッション分割と知識の活用
そう、だから調査フェーズと分析フェーズと整理するフェーズと実装計画を設定するフェーズを全部セッション変えたりするもんね。結構絶対に成功させたいなみたいな時は。
うんうんうん。
あ、そうなんだ。
確かに今言われて納得感があるというか、なんかバックエンドの開発とかしてて、データベースから考えていくと、もうデータベースを管理するための画面が出来上がるみたいな。
そうそうそうそう、なんかデータベース、ユーザーとかじゃなくてデータベースを管理しやすいためのモデルとしてUIに表出していくから、まあそれは確かにユーザーフレンドリーではないよねみたいな。
確かにね。
で、そことバッティングするから多分、まあそのいわゆるビジネスサイドとかUI、UIにつながる人とエンジニアサイドが揉めるみたいな組織が多いみたいな。
あー、なるほどね。
だって、2人ともその話する起点が違うから。
確かに見てる世界線がもう違うというか、見てる方向性が違うからね。
そうそうそうそう、なんか画としているモデルがそもそも違うみたいなのがあって。
で、それは例えばなんか調査して分析させるのも、調査フェーズっていうのは発散フェーズで、より多くのものをよりこうフラットに収集して事実情報をバンバン入れていくみたいな感じの状態。
発散フェーズから次分析すると、その中で最適解なんだっけっていう風に、次収束させるフェーズに入るけど、
これをなんか調査分析お願いしますみたいなんで言うと、調査する時のメンタルモデルと分析する時のメンタルモデルは真逆の方向に向くはずなのに一緒くたにやるから、
調査して全部情報が揃った上で分析をお願いします。
まあ1セッションにやるにもそうするし、なんだったら調査さすだけさすみたいな感じで、
で、こんな感じの調査状況になっているんですけど分析してくださいっていうのを別セッションにお願いするみたいな感じの。
ああ、確かに。
なんか言われて、それを考え、その話をされてみると、確かに単純に調査した時のセッションと、
それを元に分析してもらうセッションって、
まあ一緒でもいい時もあると思うけど、分けた方がより良い結果が得られそうなんだろうなっていうのは、
僕のイメージだとずっと調査させたらその時いろんなものを認知、知覚しているので、
そのコンテキストを有効活用した方が分析って、より深く分析できるんじゃないかなと。
はいはいはい。それはだからユーザーからすると楽っていう話よね。
だってそこで得た事実情報を全部整理させて、次のAIに引き継ぐのって結構めんどくさい。
まあめんどくさい、そうだね。
そうそうそうそう。だからユーザーからしたら楽っていう話なのかなっていう気がする。
はいはい。まあ確かに。
まあもちろん分けなくても良い成果得られる時もあるけど、分けた方がきっと良いんだろうな。
まあだからより確実に進めたい時は多分分けた方が良い。
だからなんか今この作業をしてもらうのにどういうメンタルモデルが必要なんだっけみたいなのを、
結構多分ずっと考えるみたいな。
うんうんうん。
知識の引き出しと「物差し」としての活用
あとはあれだよね、そのAIがもうすでに知ってるだろうコンテキストっていうのがあるじゃないですか。
その名称として、概念として知ってるみたいな。
なんちゃらの法則とかもそうだし、こういうデザインフレームワークみたいなとか。
うんうんうんうん。
それをあえてこうこと細かにルールにしないっていうのも結構大事なのかなって。
まあそうだね。なるべく一言で全ての、
情報を与えられるのであれば、もうすでにモデルが持っている情報を有効的に引き出してもらうみたいなね。
うんうんうん。そういう技として暗黙的にそういう風に明示するみたいなのは結構あるあるというか、やる必要があるよね。
確かにテストしてもらうときにテストのやり方をステップバイステップで全部説明するよりは、TDDとかの原則に基づいて検証してくださいみたいな。
言うだけで終わるとかね。
うんうんうん。そこが結構AIの認知としてさ、この考え、それをどういう考えがあるかなみたいなのを。
例えば考えさせるとか収集させるときとかに、いやなんかAI時代それなしでしょみたいなのもあったりする。
まあ確かにね。
うん。だから結構なんかその、こういう時はこの考え方、こういう時はこの考え方、こういう時はこの考え方、でその上にさっき言った、
その裏の背景としてはこういう根本的な考え方があるから、使うフレームワークはケースごとに違うんだけど、この前提の考え方だと一貫してるよねみたいな状況を。
これは多分人間側がうまく設計させないといけないというか。
うんうんうん。
これはスキル設計みたいな話なのかな、どっちかというと。
うんうんうん。
だから最近あったのがあれですね、そのなんかタスク思考型とオブジェクト思考型のデザインパターンみたいなのがあって、
タスク思考型ってまあいわゆるタスクをこなす上で、例えば登録するから登録するじゃあ何をみたいな感じで画面の階層を踏んでいくパターン。
で、オブジェクト思考型っていうのはその何をっていうのが登録するっていうのが例えば請求書とスタッフとシフトみたいな感じのやつがあったら、
シフトとスタッフと請求書をまずはユーザーに見せてその中で登録するっていうことを選ばせるみたいな。
逆にタスク思考型は登録するを押してから人なのかシフトなのか請求書なのかを登録させるのを選ぶみたいな。
で、多分今回のパターンで言うとオブジェクト思考型のUIの方が結構多分合ってる、適切にだっていう風になるんですけど、
一方でなんかその場合によってはタスク思考型の方が良かったりする。
うんうんうんうん。
例えばシフトとシフト提出と働けるよっていう提出と休暇っていう提出があったとしたら、
提出するシフトなのか休暇なのかっていう風にタスク思考型的にやってもらった方がUI優位が非常に良いよねみたいな感じなので、
この2つの概念で全く別々の概念として取り扱われたりして、だから基本的にオブジェクト思考型のUIで考えてくれみたいなことを例えば言ってると、
全部オブジェクト思考UIで定義されてる感じになるから、それはちょっとおかしいよねと。
だから条件分岐を考えないといけないみたいな。
うんうんうん。
シンプルな機能とかだったらタスク思考で十分だったりする時もあるけど。
そうそうそう。多すぎるとみたいなとか。
うんうんうん。
多い場合は、うん。
そう考えたら僕全然タスク思考とかオブジェクト思考って、以前ヤマチャに教えてもらってそういうのあるんだと思ったけど、
AIに指示を与えるためにどういう引き出しというか、手玉としてワードを持ってるかっていうのも結構重要になってくるんだなみたいなのは。
うんうんうん。
開発をしてる時にこういうのがよくパターンとしてあるんだけど、世界ではそれを言い慣らすような概念ってありますかみたいなことを聞いて。
うんうんうん。
何々の原則みたいなのがありますかって聞いてくると結構探してくれるじゃないですか。
うんうんうん。
それを元に自分が求めているのに近い原則とかを見つけて、それを伝えてあげるとその一言で一気に解決したりするかみたいなのは重要になるんだろうなみたいな感じがする。
知識の罠とAI時代の最強パターン
でもなんか俺ここで一個、なんか引っかかり?引っかかり?っていうか罠があると思ってて、今のアベちゃんのことだけを聞くと一般的には知識を蓄えてる人の方がいいという風に傾くと思うんですよね。
色んなフレームワークを知ってる方が判断がしやすいからっていう風に傾くと思うけど、俺結構それが罠だと思ってて。
探索フェーズにおいては自分も知ってることはあるんだけど、おそらく知らないこともいっぱいあるだろうっていう初心に帰ってわーって探索してもらって、
その上でそこのバーって拾い上げられた情報の中から、それを理解するために自分の今持ってる知識っていうのを保管材料としてものさしの一つのメモリとして使う、あくまでも使うだけってしないと、
自分がモノCDだみたいな感じの辞任があったとして、その結果人は調査フェーズを差し込まなくなるんですよね、ここで。
確かに。
これは罠だと思ってて、だから自分の知識量っていうのは常にどれだけものを知ったとしても足りないものであるっていう前提を持って、
けどそれを収集した時に把握するためには、時には自分が今まで得た知見とかをものさしに使って、あくまでも知識を理解するための材料の一つとだけみなして、
全部フラットに考察していくというか、今これ何がいいんだっていうのをしないといけないから、単純に知識量がものを言うとなると、
俺は変に知識を持ってる人よりフラットに全部見切れる人の方が強いなみたいな感覚になる。
スペシャリストであればあるほど、自分の知識の前提に縛られてしまうというか、感覚はあるかもしれない。
僕もヤマジャンと話しててたまに思うのが、僕はシステム開発を基本的にずっとしてきたので、
こういう開発をする時ってこういう原則だよねみたいな前提でスタートしてしまうことが多くて、
AIの指示もこうしてくださいみたいな話で結構スタートしてたりすることが多いんですけど、
でも一方で色々調べてもらったらこういうのあるみたいなんだけどってあれで、うおーまじかみたいな。
たまにヤマジャンからね。
超近道みたいなやつね。
なんか全然わかんないけど聞いてみたらこんなのあるらしいんだけどって言われて、
そんなやり方があったんだみたいなのをたまにあるからこそ、
なんか今までっていろんな経験を積んでいろんなパターンを自分の中に醸成していくことで
スペシャリスト的にいろんなことができるようになるみたいな感覚でいたんですけど、
その感覚を持ち続けていると逆に糧になるんだなっていうのを強く思って感じましたよね。
僕が思うに一番最強パターンは今までスペシャリストでやってきた人が
自分は無知であるっていうことを自覚して、
その上でAIエージェントとかに色々調査をさせてもらった結果を
自分の今まで持ってきた経験とか知見を生かしながら
より早く理解できて、より精度の高い、これが一番本質的だろうみたいなのを
見つけれるっていうところだけにその知識と経験を活用して
取捨選択をしていけるっていう人がもしいたなら、
その人が多分今のAI時代最強なんだろうなみたいな。
確かに。でもなんかこう、ここでまた難しいなと思ってるのが、
AI時代の、例えばこう開発の話に限って言うと、
人間がコードを書いてた時代のコードの書き方って
あくまでも人間が認知できるその幅が
AIよりは当然すごく狭いがゆえに
その整理が原則として良いとされているみたいな大前提があって
脳の思考回路的にも常にコンテキストを狭めることに
すごく集中してしまうことがあって、例えばDDDとか
いわゆる世界で使われているような開発の考え方
オブジェクト思考とかDDDとかいろんなデザインパターンがあるもの
全部コンテキストを狭めて影響範囲を狭くするみたいなところに
思考してしまっていて、それをアンラーニングして
AIと会話するじゃないですか
結局良いなって思うのは、今まで良しとしてきたものに
自分が良いと思うのがそっちにアジャストされる
なるほど、AIコーディング時代じゃない時にコーディングしているがゆえに
ペストプラクティスだと認知するバイアスが
すでにそっち側にかかりやすくなっているみたいな感じ
でもAI時代ってもうDDDとか関係なくてみたいな
アーキテクチャーの考え方自体ももう変えなきゃいけないじゃん
みたいなフェーズにも来ているとは思っているので
そう考えると本当に何にも無知の人が
どう開発したら円滑に済むのかってゼロベースで考えた方が
もしかしたら良い
本質的にね
本質的にたどり着く可能性が高かったりするんじゃないか
それはなんかちょっと僕の中では
人と認知って相対的だと思うんですよね
だから関係性だと思うんですよ
基本的にだから自分が持ってた知識を柱にして
それと比べてどうだろうだと思う
基本的には
そこの柱がある人の方が
もちろんバイアスとかがあるっていうのは
それは副作用的な話であって
別に柱を持っていても
ノンバイアスにできる方法はあると思っていて
だから結局どこまで行っても
俺の最強パターンは
やっぱりその柱を持っている人が
ノンバイアスに思考できるっていうパターン
本質って何なんだろうっていう風に
思考できるパターンがやっぱ最強なんだろうな
っていう風に思っていて
だから
「物差し」としての知識とバイアスの分離
例えば俺が全然知識がありません
だからこそゼロベースでフラットで考えれるっていうのは
そうなんだけれども
けどもともと人間がやる前提だった時に
これがベストプラクティスであって
それがAIエージェントをベースとした
コーディングになった時に
こう変わったから
これが本質だろうっていう風にはならないんですよね
そうそう
比較対象じゃないんですよね
けど人の思考は基本的に
僕はそれの代わりに
前言ってた羊とか料理とか
今までの自分の経験を
ある種の柱と見立てて
適当に
そこから相対評価しながら進むっていう
手法を多分取ってると思ってて
けどそれはあくまでも開発分野じゃないものを
相対的に柱と
擬態化させて柱として
考えてるみたいな
思考法だから
あくまでもやっぱフェイクなんですよね
もちろんそういうパターンから
全然また全然違う
世界が見えるみたいなこともあると思いますけど
基本的にやってること
どんだけゼロベースっていっても
アメちゃんからすると僕が
ゼロベースで考えてるって見えるかもしんないけど
僕は僕の中にある経験を通して
相対的にその物事を見てる
なるほど
ってことはやっぱり柱とバイアスっていうのは
違うものであって
分離できる話
本質をついたこととして
何が大事なのかっていうのを持ち続けているところ
物差しなのかな
物差しのメモリ
人は長さを測るときに
メモリがないと測れないわけですよね
物差しがなくて測れる人っていうのは
手の長さが何センチぐらいだっていうことを分かって
それを柱として
物差しとして
見るわけじゃないですか
そこの距離感とかそういうのっていうのは
やっぱ何かしらの
いるわけですよね認知してる
だから僕と今の
例えば目の前にある冷蔵庫の距離が
遠いか近いかっていうのは
それは今までの経験上
近いのか遠いのかっていう
判断を下してるから
柱はだから本質ともまた違いますよね
何かその物差しみたいな
なるほど物差しか
何か
手段が変わったとしても
手段というか
使える手持ちのものが変わったとしても
残り続けるって何かみたいな
それが物差しなのか
物差しじゃなくて手なのかみたいなのが
変わったとしても
測れる量を
自分の中に持ってるかみたいな
だから多分
AI時代の開発と「物差し」の進化
例えばテスト偏差値とかさ
テストの点数とかみたいに
数値化されたりフォロワー数とかってやって
人間がそれに躍起になるっていうのは
数字って一番絶対的な物差しだから
普遍なわけじゃないですか
高い方が
88点より89点の方が高いよねっていうのは
みんなちゃんと認知できるから
それが便利だからそれを使ってるわけですよね
だから数字も物差しなわけですよね
けど
本質的には別に
89点が高いか低いかなんて
テストの難易度によって
変わるわけじゃないですか
超簡単なテストで89点だったら
いや何で100点取れないのみたいな
低くないみたいな話にもなるし
逆に超難関だったら89点も取れて
すごいねみんな10点なのにみたいな話だし
みたいな話なんだけど
けど点数が
その点数っていうか数値がやっぱ
なんか認知しやすい
物差しの一つだから
そういう風に
活用されてるみたいなのがあると思ってて
でそれがもうちょっとなんかその
抽象像の高い物差しとして
今までの経験みたいなのがあったりとか
だから人がやってた
コーディングをしてる時の
仕組みってこうだから
こういうのが良しとされてたけど
AIになったらこの部分が変わるから
こうだよねみたいな感じの感覚を
よりやっぱ得やすい人っていうのは
そういう近い世界の物差しを持ってる人の方が
確実になんかその
推定する精度が高くなるはずだろうな
って思ってて
けどそこにバイアスとかが邪魔して
なんかこう戻ってきちゃうみたいな
けどなんか人間でコーディングしてた時代に戻ってきちゃうみたいな
バイアスとかもあるけど
それは副作用の話で
それを取っ払えたら
たぶん一番最強なのはそっちなんだろうなみたいな
そういうことか
目的達成と手法への非固執、無知の自覚
何をこう
満たしたいかをちゃんと分かってるっていうのは
例えば長さが
距離を遠いか近いかを
知りたいっていうことをちゃんと認識してて
その過程で
なんかメモリのある定義が大事なのか
指で数えるのかっていうのは
バイアスとして取っ払えて
単純に近いかどうかだけを
確かにね
認識できるみたいな
確かに
だから目的確かにそうですね
達成したいことがよりはっきりしてる人の方が
バイアスとかそういうのを捨てきれる
可能性は高いかもしれないですね確かに
もちろんその中で距離を測る方法って
10通りぐらいあってみたいなのを語れて
それがあるからこそ
距離の測り方って今の時代に
おいては何がいいんだろうっていうのが
積み上げれば理解できるというか
10通り知ってるからこそ
20通りになった時にその残り10通りは
把握しやすいみたいな
比較対象がいっぱいあるから
そういうことだよね
確かにな
それを持ってない人がやっぱ
それを理解するのって結構
弾力もいるし時間もかかる
作業になるし
それを理解したって思ったとしても
その理解度ってどれくらいなんだろうって
結構疑問なような気がしてて
確かに
結局それを理解したって思っても
そもそも物差しを持ってないから
その理解が正しいかが
測れないというか
実際その理解のことを測ってみたら
めちゃくちゃ遠いと思ったら
実際はすごい近かったみたいなことが
起こり得るから
だってシステム開発してるのに
料理を物差しにしてたらさ
それが確からしいからか全然分かんないよね
まあ確かに
そう考えた
そっか
じゃあやっぱり
何が重要かっていうのは
持ち続けてかつ
その重要さを満たすための
手法に対してはとらわれない
バイアスをかからないように
意識しなければならないってことだよね
あとは自分は何も知らないという
自覚を持つっていう
どれだけ知ってても
そうだね
いろいろ手をかけて
過去の知識の活用とAIのバイアス
作業を始めようとすると
自分なんか
てかあれだよね
やっぱ訓練されてるから
これをしたいって言われた瞬間
頭の中にこういう手法があるっていうの
3つくらい
そこにロックされちゃいがち
みたいなのがあるからね
なるほどね
そこ
その3つとか思いつくと
便利だなって俺は思っちゃうね
逆に調査するときに便利だな
みたいな感覚に思っちゃうね
確かに
だから多分同じ
俺だって同じ開発っぽいことをするときで
毎回全く知らんふりして
AIに聞くもん
同じ開発
だからもう自分が知ってるようなこと
文字起こしの
例えばASRで文字起こしする仕組みについて
作らないといけないみたいな感じになったときに
1ヶ月前に
すでにもうASRで仕組みを作ってるとするじゃん
自分自身が
だからある程度そこにおいては
結構なんかちゃんと認知してるなみたいな感じの
GIFがあったりとかして
全然知らんつもりで聞くっていう
それはなんか2つの要素があって
まずそもそもその時の手法が
その時調べた中では最適解だと思って選んだ手法なんだけど
別の角度から見たら最適解じゃない可能性があるっていう可能性が
多分20%ぐらい潜んでる気がするっていうのと
あと1ヶ月も過ぎてたら
技術が進歩してるから
より良い選択肢がある可能性があるっていう
なるほどね
あんま考えないな
考えなかったのそれは
なんか目に見えてるからこそみたいな気持ちで
もうこれとこれとこういうタグがあるからみたいなのは
固定でやりがちだったかもね
そこがすごい機械ソースに感じちゃうよね
なるほどね
もしかしたらその20%引いたりして
ブレイクするというか
今までできなかったことができるようになるかもしれない
そうそう
シンプルよりシンプルにより高精度により安価にできるようになった
普通にあり得る
これが厄介なことで
AIのバイアスへの対処と事実・推測の分離
AI自身もそういうバイアスを携えてるから
そもそもね
あれが知識のカットオフがあるから
それも加味しながら
AI自身もやっぱ知らないことがあるっていう前提を持って
だから今の日にちは絶対伝えるようにするとか
そうなんだ日にちも伝えたりするんだ
日にちを伝える調査系はマストで
あと結構あるのが
GitHubのスター数とか
やっぱりAIも定量的なものに弱いから
人と一緒で
古くからあるとか
開発が活発に行われてるとか
おそらく確からしそうだなみたいな
それっぽい確からしそうな情報を
いっぱい携えて持ってくる
それは信じないっていう風にしてる
信じないんだ
だから前提
こういう前提があって
しかも例えばAIでこういう風にやっていくみたいな
例えば今のLLMだって
これくらいまでできるようになってるっていう
前提に立った時にどうかみたいな
前提であえて
良い方向にバイアスをかけてあげる
みたいなことも重要だと思う
確かにAIが調査して
こういうのが良いです
しかもライベラリーのスター数がこうなので
みたいなことを言ってるときに
それが本当に
評価として
コミュニティが全体として評価してるからいいものなのか
本当に仕組みがいいものなのかは
分離して考えてるってことだよね
分離して考えないと
そもそもそれって人間がやってた時代の時の話だよねみたいな
全然AIネイティブな作りじゃないから
しんどくなりそうだよね
もっと良い方法
抜本的な良い方法ができそうだよねみたいなとか
そういう色んなパターンがあると思ってて
そこは逆に
フラットにも結構危険だなっていう気もしてて
確からしそうな情報を携えてきてるから
そうだね
だからそうするとセッションをいっぱい立てたくなるよね
いくつかの前提で
いくつかのパターンで重み付けしてあげて
バイアスもかけたバージョンとバイアスかけてないバージョンと
調べさせてみたいなとか
だから調べさせる時に評価はさせずに
とにかく情報だけ収集してくださいみたいな
評価はしないみたいな
こういうやり方があるっていうのをひたすら解説してもらったものを携えて
別のセッションに移って評価してもらうとかじゃないと
結構バイアスかかっちゃうよね
そうだからドキュメント化する時は結構調査したものは
事実と推測を必ず分離して
事実情報だけを保存するようにしてくださいみたいなのは言うね
人が普通にやったら混ざりそうなことは
基本的にAIも混ぜこぜでやってくるっていう
期待値で挑むっていうのは結構大事かもしれないね
確かに
それで言うと僕も最近
プロジェクトのドキュメントを整理してもらうときにやってるのが
フォルダごと事実情報だけが入る
フォルダとそこから考察された
AIが考えた結果を出してもらうフォルダをもう分けてもらう
っていうのをやったりしてますね
結構
仕事をもらっていろいろ打ち合わせとかするとき
の情報ってある意味事実情報じゃないですか
それを議事録としてまとめてもらったものを
議事録だけを放り込んでしまうと
ちょっと文字起こしがミスってたとか
議事録の起こし方がちょっと悪かっただけで
嘘にもなりかねないなと思っている
そういうときは文字起こしっていうのと
人間が書いてたテキストっていうのは
事実情報のフォルダに突っ込んで
AIには議事録を作ってくださいって言ったら
そこから推測された結果だけを入れる
フォルダに書き出してもらってもう分離して考えてください
みたいな感じで事実情報としては残り続けるんで
マインドのアップデート必要だなって思ったときはちょっと網羅的に確認して
ずれてそうな部分は更新してくださいって言うと
事実情報のフォルダには一切手を加えず
推論した結果のフォルダだけがとにかくブラッシュアップされていくみたいな
それいいね確かに二段構成
そういう構成とかにして
間違いとかバイアスかかりにくくするっていう工夫はしたりしてますか
意外と暗黙的に
人がいい感じに混ぜこぜでやっちゃってるとか
っていうのを分離してあげるのは結構重要かもしれないね
やり取りする中で
まあそんな感じかなですかね
まとめと今後の展望
はいそんな感じですかね
じゃあたまにはこういうゆるい話を
思いましたので
結構喋りましたね
ゆるいけどね普段はモデルがどうこうっていう話ばっかりだけど
どう使ってるのかみたいな話もあるよね
確かにじゃあ本日もありがとうございました
ありがとうございました
本日もAI駆動開発部の日常をお聞きいただきありがとうございました
いかがでしたでしょうか今回は
AIとのやり取りどういうふうにやってるかっていうある意味初心に戻るような
回でもあったのかなというふうに思うんですけれども
こんな感じで日々AIとやり取りしながら
知見をまとめていってるのでこういうトピックを話してほしいとか
気になる点あればいつでもお便りとかコメントいただけると
嬉しいですこのPodcastが気に入ってくれた方はいいねやフォロー
高評価ぜひお願いいたしますそれではまた次回もお楽しみくださいバイバイ
