AIを『採用』しアサインするツール adptのコンセプトと未来
こんにちは、TAM AIチーム 代表の佐川です。
今回は私たちが開発しているLLMプロダクト「adpt」ついて簡単に紹介し、主にそのコンセプトについてお伝えします。
弊社では4月よりAI専任チームを立ち上げ、社内ナレッジの交換やセミナーの開催を行い、またAI時代の制作や働き方を探るべく仮説検証としてのプロダクト開発を行なってまいりました。
adptは、その過程で得られた知見を活かし作られているものです。
本稿を読んでもし何かご意見などございましたら、お気軽に連絡いただけると幸いです。
adptとは
adptは、AIを新しいチームメンバーのように扱い、日々の業務をよりスムーズに進めることができるツールです。普段のワークフローに自然とAIを導入でき、効率的に仕事をこなせるよう設計されています。
使い方はとても簡単で、
欲しい成果物を定義する
適切な人材(AI)をアサインする
作業のための参考情報を与える
という3ステップとなります。参考資料を準備し、誰かに仕事を依頼するのと同じような感覚で使えることを目指しました。
渡す参考情報もまた別の作業の成果物です。
したがって、以下のように人材と成果物をつなげることができ
フローを作成し、スムーズにAIに作業を任せることができます。
最後に出来上がった資料をダウンロードして作業は完了です。
とてもシンプルな体験ですが、ここに至るまでに様々な検討がありました。
adptのコンセプト
adptの目指すビジョンは、現在の生成AI技術を誰もが扱えるようにし、柔軟かつ最高の効率で仕事に活用できている世界の実現です。これを読んでくださっている方であれば、同じことを考えていらっしゃる方も多いのではないかと思います。
adptはそのためのアプローチとして、
慣れ親しんだメンタルモデルの継承
知的生産の規格化（あるいは工場化)
Human-in-the-Loop（ヒューマン・イン・ザ・ループ）
この3つのコンセプトを立てました。
まずはメンタルモデルについてお話ししていきます。
慣れ親しんだメンタルモデルの継承
LLMアプリケーションといえばChatGPTです。ChatGPTはその名の通りチャット型のUIを搭載しており、このUIこそが今回の論点となります。
まずは再度ChatGPTのUIを見てみます。
一見慣れ親しんだ画面ではありますが、実際に使うにはたくさんの思考が必要です。聞きたい主題の選択に加え、適切なインストラクションやプロンプトエンジニアリングなどなど。
これは私たちの行動を促したり限定するものがなく、いわば言葉の海に放り込まれる為に起こります。
このユーザーの負担を強く意識したのは、弊社のキャラクターChatbot「TAMくん相談チャット」を作っている時でした。キャラクターがそこに存在するだけで、ChatGPTと比較し自分の意識が変わったことを実感したからです。
文章を入力する必要はないので、一度アプリを開いてから戻ってきてください。https://tamkun-sodan-chat.vercel.app/
いかがでしょう、なんとなく私たちの行動が限定されたことに気が付きましたでしょうか。
キャラクターが目に映ることで「会話」が自然と促され、「キャリアのことを相談してほしい」という言葉により「会話の方向性」が決まります。
この適切な限定によりユーザーが文章を作る負担がグッと減り、体験の種類が変わることを実感しました。
これはデザインの文脈におけるシグニファイアやアフォーダンスという概念と深く関係します。
シグニファイア(signifier)はその元となるサイン(sign)から考えるとわかりやすいでしょう。その名の通り何かを指し示すもの、記号や手がかりといった意味です。
アフォーダンス(affordance)は「ある対象物と私たちとの可能性」となります。
例えば私たちはドアノブという記号を与えられると
「ひねって開けそうだ」という可能性を意識的、無意識的に抱きます。
最も重要なことは、なぜ私たちは「キャラクターに話しかける」ことや、「ドアノブを捻って開く」ことができるのか。
それは過去にそういった「行動により成功した経験や記憶」「こうすればああなるなだろう」というメンタルモデルを持っているからです。
このメンタルモデルこそがadptで大事にしているところです。adptのゴールは「仕事にLLMを取り入れる上で最高にわかりやすいもの」でなくてはなりません。
したがって、adptのユーザビリティは現在の仕事のメンタルモデルに徹底的に寄せることにしました。具体的には「外注」や「依頼」です。
新しいプロジェクトを外部の専門家に依頼するときのように、adptではAIにタスクをアサインし、必要な情報を提供することで、AIがそのタスクを遂行します。
まとめると、
最終的にどんな成果物が必要だろうか
誰に頼んだら良い仕事してくれそうか
そのために必要な情報は何だろうか
私たちが仕事を依頼するときに念頭におく、この3つこそがadptの軸です。
「欲しい成果物を考えて人材をアサインする、そのために必要そうな情報を与える」というシンプルなフローとなります。
また、adptでは基本的に指示のプロンプトは使用しません。専門家に依頼するときのことを想像すると、詳細なやり方の指示は出さないことが多いはずです。
私たちが真に着目すべきはその専門家がどのように仕事をするかではなく、成果物そのものとなります。したがってユーザーの負担となるプロンプトエンジニアリングなどは隠蔽しadptは開発されました。
知的生産の規格化 (あるいは工場化)
ここからはadptにおいてどうクオリティ担保するのかという話に移っていきます。
adptは仕事を効率化するアプリケーションですが、そもそも普段私たちがチームの成果物のクオリティを担保する上でとる対策は何か。
１つはマニュアルを作ることです。これは仕事の仕方、アクションに基点を合わせたものになります。どのように仕事をすれば良いか、細かな道筋が与えられるためマニュアルを与えられた人間はゴールに辿り着くことができます。
２つめはフォーマットやテンプレートを作ることです。これは成果物、状態に基点を合わせたものになり、「どのような成果物ができていればゴールか」と言い換えられます。所定のものが入手できるようゴールの基準を制定し、その道筋については問わないスタンスです。
これは場合によって使い分けられるべきものであり、また両者は明確に分けられるものでもありません。
例えば、初めてPCの使い方を学ぶ際にゴールだけ与えられても操作がわかりません。一方で私たちが普段PCを使っている際には結果を意識しており、私たちの入力に対して想定通りの成果が得られれば内部の処理や動き方は全く気にしないでしょう。
これらの方向性において、adptでは基本的に後者のゴール-フォーマットを明確にする方針を取ります。理由は「情報の抜け漏れをなくしクオリティを担保、判断ミスをなくすこと」「過程を入れ替えやすくすること」の２つです。
まずは情報の抜け漏れについてですが、フォーマットやテンプレート化によって成果物のクオリティが担保できる点は直感的です。そして、このクオリティの担保が「判断ミスを無くす」ことにつながります。
誰かの作業によって出来上がった成果物は、また誰かの作業の参考情報-インプットになるということです。
例えば要件定義書をAさんとBさんでつくるとなると以下のような図ができます。
この際、ヒアリングシートに載っているだろう情報が欠落しているとどうなるでしょうか。Bさんは正しい判断ができず手戻りが発生したり、そのまま作業を進めるのであれば少ない情報でクオリティの低い要件定義書を作ることになります。
これは工場を想像するとよりわかりやすいです。ラインがある中で、もし異なる規格の部品が流れてきたらどうなるでしょうか。生産機械は厳密さが求められますから、そこで生産はストップしてしまいます。
また、試しにあなた自身が前の担当者から以下２つの異なるデータどちらか一方が提出されたと仮定してみてください。
どちらも元は同じデータですが、フォーマットの違いによって判断のしやすさやそれに伴う処理が大きく異なってくることがわかります。
これが「フォーマット化によるクオリティの担保と判断ミスの阻止」です。
さらに、ワークフローをフォーマット基点とすると手段の置き換えも簡単になります。
例えば先ほどの例のAさんを置き換えるとしましょう。
人材の入れ替わってもBさんはあまり困りません。なぜなら、渡されるデータは以前から大きく変化しないためです。
これもまた工場を例にとってみましょう。ラインを効率化するために機械を新調し、機械Xを機械Zにしました。しかし次に渡される部品の規格は変わら
ないため、混乱は起こりません。
また、最新機械αを導入したとします。ここで、規格さえ定義できておりインプットとアウトプットが定まっていれば比較的簡単に作業を繋ぎ直すことができます。
以上がコンセプトの２つ目、知的生産の規格化です。
adptではフォーマットを定義し、それに沿って文章生成させることにより抜け漏れなく判断しやすく、また過程を入れ替えしやすくすることを狙いました。
これまで「判断」という言葉を使ってきましたが、これはLLMだけに向けたものではありません。結局のところ、最終的に成果物に対して評価を行うのは人間だからです。
これが、最後のコンセプトに関わります。
Human-in-the-Loop（ヒューマン・イン・ザ・ループ)
理想を言えば、AIに仕事を任せるのであれば簡単な言葉から一気に最終成果物を作り出せれば最高です。昨今ではAI Agentの隆盛もあり期待が大きく膨らんでいる分野かと思います。
しかし私自身AI Agentがとても好きな分野ですが、今現在ではこれが不可能だと考えています。最も大きな理由はAIとの共通認識が持てずAIが誤った方向に進むためです。
例えば今「りんご」を想像してください。今あなたの頭の中の「りんご」はどういったものだったでしょうか。青りんごを思い浮かべた人もいれば、すでに切られているりんごを想起した人もいるでしょう。
このように言語を介して共通認識をとることは困難であり、頭の中のイメージは言葉にした時点で情報は極端に失われます。
さらに、この情報が失われた状態でプロセスが進むと私たちが想定していないゴールに辿り着いてしまいます。
これはLLMにおける「前の文章に続く最もらしい文章を生成する性質」によるものです。一度方向性がずれると、その方向に向けてどんどんと進んでいってしまいます。
ここにおいて、人間がプロセスに介入すれば頭の中のイメージをそのままに文章のズレを修正することができます。
このような概念は機械学習の分野におけるHuman-in-the-Loopとして語られます。
機械学習はその性質上誤りをなくすことができません(これは現在のLLMにおけるハルシネーションに強く関連する事象です)。
したがって、機械学習の実運用では判断を機械学習だけに任せるのではなく、人の判断をそのシステム内部に挟み込むべきという意見が提唱されてきました。
これについて、私はLLMを用いたアプリケーションでも変わりないと考えています。
そこで、adptではHuman-in-the-Loopを念頭にAIと人間がコラボレーションするための場所となることを目指しました。
この側面からも、先ほど挙げたようなフォーマットをベースとした仕様に決定しています。
提出される資料の構成が毎度異なる場合、人間がチェックする負担が増大するためです。付随して、レビュアーがわかりやすいようどのような思考でこのアウトプットが出たのかというworklogが添付されます。
さらにAIの成果物はエディタから編集可能であり、次の作業に移る前に積極的な介入ができます。最上部にダウンロードボタンがついているため、好きなエディタで作業することも可能です。
他にも成果物やメンバーの繋ぎ方を変えたり、フォーマットを変えたりすることでAIのシステムに人間が介入しワークフローを漸進的ブラッシュアップできます。
まとめ
以上がadptのコンセプトでした。
誰にとってもわかりやすく扱え、効率的なワークフローが作れる。そのために「仕事を依頼するメンタルモデルを踏襲、フォーマット化と人間によるAIプロセスへの介入により実現するアプリ」がadptです。
現在αテスト中であり、こちらのLPで事前登録の登録を受け付けています。ご興味が湧いた方はぜひご登録ください！
未来展望
最後に、adptがこれからどのように進化していくのか、そのビジョンを共有したいと思います。
まずはソースコードを公開しようと考えています。LLMの発展はたくさんのOSSの上に成り立ってきました。我々としてもこの全世界的なコミュニティ主導での発展に貢献したい気持ちが強くあります。
また、ワークフローを扱う際に一企業にデータを託すことはリスクと判断されるケースがあります。そういった方々向けにセルフホスティングできるよう選択肢を与えることも公開理由の一つです。
ライセンスについては未定ですが、できるだけオープンにできれば嬉しいです。
次に性能の拡充です。CSV, 画像ファイル, Wordファイルへの対応を予定しています。テキストを扱えるだけでは十分といえず、普段我々が使っているファイルが使えなければスムーズなAIとの共同作業はできません。具体的にはChatGPTにおけるAdvanced Data Analysis(CodeInterpreter)やImage to Textモデルの統合です。
関連して、アサインできるAIのAI Agent化を進めたいと思います。個人ではなく組織がアサイン可能になるイメージです。インターネットへのアクセス性を高めることも理由の一つです。AI Agentはまだ発展途上であるため、数ヶ月〜一年後に導入できればという感覚です。
以上が未来展望となります。
もしadptの開発に興味がある方は、ぜひ連絡をください！
X(twitter)でお待ちしています！
まだ生まれたての成長過程のアプリですので、機能やビジョンについてみなさんと話ができればとても嬉しく思います。可能性があるプロダクトだと感じている一方、可能性を最大限に引き出すためには、たくさんの意見やフィードバックが不可欠だからです。
これからも皆さんと一緒に生成AIの未来を作っていければ幸いです。
それでは、最後まで読んでいただきありがとうございました。