広木大地さんの新刊。
AIと、エージェントは、あまり区別なくとらえるのが一般的な見方だと思うけど、AIではなくAIエージェント、というのが主題の本。
言われてみるとそうだなと思って、チャットとしての利用で、問題のディテールの質問だけをして、あくまでアシスタントとして使い、人間主体な利用をしている人もいれば、目的を伝えて自走してもらい、人間はフィードバックだけしている、という人もいる。
AI利用、ではなく、エージェント化を推進して、不確実性の低いタスクは自動化していき、人間はより難しいことや価値の捻出に時間を使わなければならない、という目線を手に入れられる。
自分たちの環境だと、コーディングに関しては、お願いしてみて、うまくいかなかったことをinstructionに入れていく、という形でフィードバックループを回して、知識を貯められるようになっている。
instructionもAIが触れるところに置いてあるので、うまくいかなかったら内省してルールを追加させることもできる。こうなったら、あとは使っているだけで良くなっていく。
以前のコーディングタスクでは、来たときよりも美しく、コードを整えて帰りましょう、という意味だったけど、現代では、instructionを洗練させて、二度とのこようなフィードバックをAIに対して行わなくても済むようにすること、という、instructionを整えて帰りましょう、という意味になっていくと思う。
コーディング以外の活動では、あくまでAI利用にとどまっていて、何かのドキュメントをAIから読める場所に置いてみて、情報を引き出す、にとどまっている。
こういった業務フローもすべて、動かしてるだけで知識を蓄積していけるようにするには？ということに関心がある。
ざっくりした見積もり、ざっくりとしたプロトタイピング、ざっくりとした要件整理など、たたき台はまずAIが作る→人間が見て成果物に対してチェックするとともに、AIが読む情報源やinstructionも調整していく、というのを基本の型にしたい。
今日の時点では、リポジトリにテキストファイルとして置いてる場合と、それ以外の場合、たとえばGoogle Docsに置いてる場合で、扱いやすさが全然ちがう。
NotebookLMから読んでくれるようにはなったものの、それではAIから読める、というだけで、同じソースに書き戻す、というのができない。
リポジトリに入れてしまった場合は、AIが直接編集できる、という点もそうだし、Pull Requestに乗っかることで、レビューを伴う反映のワークフローがすでに良いものがあり、pushするだけでチェックのプログラムを動かせる、というのも大きい。
という点で、Googleのソフトウェアエンジニアリングの10章のドキュメンテーションの章の価値が増してきている。ドキュメントをコードのように扱う、というところ。
abseil.io
この本とはあまり関係ない話で、Human in the Loopという言葉があるけど、人間が入ってればOK、というのも乱暴な議論なのではないか？と思って調べてたら、攻殻機動隊の引用から始まる、癖のある資料が総務省のドメインにアップロードされていた。FAT（Fairness, Accountability, Transparency）の3つが必要とのこと。一発オッケーを志さないというか、ポン出しをしないというか、AIの出力を最終アウトプットにはしない、という前提はしばらくは変わらないと思う。
https://www.soumu.go.jp/main_content/000899843.pdf
このスライドが元になっているそうなので、このスライドを予告編として読んでおくと良さそう。
hirokidaichi.github.io
