# 「ai_no_te（あいのて）」プロジェクトの裏側へ！ みなさんこんにちは。VoicyエンジニアのKii君です。 今日は先日公開されたVoicyのiNoteプロジェクト2ヶ月の歩みの続編として エンジニア視点でより深く掘り下げていきたいと思います。 前回の放送では、既エンジニアのメンバーたちがAIを使いこなして 業務をどんどんスキル化したことが話題になっていましたけど その裏側は誰がどう作ったのという声もあったので 今日はそこについて聞いていきたいと思います。 ゲストはプロジェクトの中心メンバーでエンジニアのOhagiさんです。 よろしくお願いします。 じゃあまず改めて自己紹介をお願いします。 私も同じくVoicyでエンジニアをしています。Ohagiと申します。 当初モバイルエンジニアとして入社して その領域のテックリードをやっていたんですけど 今はこのアイノテプロジェクトをメインにやっているという感じです。 よろしくお願いします。 では次のチャプターで色々質問を聞いていきたいと思います。 # 「人間の作業の延長」で終わらせない。非エンジニアが直感的に使える仕組みづくり じゃあ、プロジェクトワイのテーマの放送が決まって、 アファギさんがどのような考え方で整備していったのかについて聞いていきたいんですけど。 そうですね。結構いろいろ直接あってっていうのはあるんですけど、 最初、とりあえず皆さんにクロードデスクトップ、クロードコアークっていう、何でしょうあれは。 皆さんMacOSを使っている方がこの会社、Voicy多いんですけど、 そのMacOS上のデスクトップで動くアプリケーションのクロードを使って、 スプレッドシートの操作とか、Googleドキュメントの操作とかできるっていうものなんですけど、 当初、機能が限定的だったりとかもしていて、 例えば、ビッグクエリっていう、何て言うんですかね。 データ基盤。 データ基盤。データ分析のためのデータゲル溜まっているものへのアクセスとか、 あとはスラックへの投稿とかっていうところから皆さん使い始めていただいたのかなって感じなんですけど、 当初はGoogleドライブの操作ができなくてですね、 そのGoogleドライブを操作できるようにしたのが最初にやったことです。 考え方の答えになっているから怪しいですね。 絶対、Googleドライブを使えるようにしようみたいな、 MCP的なものを作っていたんですけど、 それは既存のGoogleドライブを使えるようになるのが一番便利だからみたいなイメージですか? そういう要望が多かった。 Googleドライブを使いたいんだけどって要望を多くいただいていたので、 それを最初に整備したという感じです。 ありがとうございます。 どちらかというと、まずヒアリングから入って、 どういう要望があるんだろうみたいな感じで動いていった感じ? そうですね。 最初は、ちょっと詳細どこまで言えるかは違いますけど、 ある業務を自動化しましょうみたいな、 AIができるようにしましょうというところから始まっていて、 最初はGoogleドライブを読ませなくてもできるような方法で、 例えば画面を作ったりとかして、 その画面上で操作できるようなものを作ったりしていたんですけど、 そうすると結局人間の作業の延長でしかなくって、 あんまり、今話しながらどういう考えでいたかというのが整理されてきたんですけど、 AIを使うことですごくスケールする箇所が多いところを AIに置き換えていこうという考え方をすごく大事にしてやってきたなという感じです。 なるほど、なるほど。 人間が操作するものではなくても、 AIに全部やってもらおうということを中心に考えて設計したという感じですね。 確かに。 実際、マホイさんエンジニアじゃないですか。 はい。 非エンジニアに使ってもらえるようにする仕組みを作るのって、 結構難しいかなと思うんですけど、 気をつけたこととかありますね。 気をつけたところ、とりあえずクロードからコネクタって形で MCPを繋げていろんな操作ができるんですけど、 結構それは皆さんどんどん使っていただいていたので、 その形で提供するのがいいだろうなと思いました。 最初はすごくいろんなことを考えたなって今思えば、 もう1回知ってみたらあるんですけど、 例えばローカルで動くサーバーみたいなものを ローカルに建ててもらえばできるそうだなって最初思ったんですけど、 だんだんそれもちょっと限界というか、 皆さんの環境、エンジニア向けの環境を構築しているわけではないので、 そこをサポートするのはちょっと、 最初はつつみさん、前回出ていたつつみさんと一緒にやったので、 1人だったらいけたんですけど、 それが2人、3人、5人、10人ってなってきたら大変だっていったので、 できるだけ自然にというか直感的に使えるようなものっていうのは 大事にしたつもりではあります。 確かに。 部署内全員で使えるような仕組みにしていこうとした時に 考えたのがMCPとか付き合いになったという感じですかね。 そうですね。 確かにそれはいいにかなっていますね。 でも実際、 パニさんはコープレートチームとかの仕事を把握し、 あんまりエンジニアなので、 最初これしていましたか? いや、これをたぶさわるまでは、 エンジニア視点での理解の仕方は一定していたという感じですけど、 例えばこういう業務ではこのデータベースに書き込んでとか、 コメント集めに行ってとかは、 なんとなくエンジニアの直感の範囲内とか、 実際にコード読んだりとかで把握してましたけど、 その外のとって、 全然知らないことがあるんだなって当初は思いましたね。 そうですね。 そこを理解していくなんて結構むずいかなと思うんですけど、 むずいです。 そこはどういう風に解決しているんですか? 全然解決はまだできていない気もするんですよね。 というのも、まだみなさん、 Googleドライブとの連結をまだみなさん使っていると思っていて、 でも究極はもちろんよしよしはあるんですけど、 技術選定とかそういう話もなってくるかもしれないですけど、 そうじゃないところ、 例えばデータベースとかに情報がすべてあって、 Googleドキュメントとか、 そういうのがあって、 そういうのがあって、 今散らばっちゃっている状態で、 最終的に集約したいなと思うんですけど、 何の話してるんでしたっけ? そうですね。 実際の業務を、 あ、そう。 どういう感じですかね。 実際の業務を、 はい。 実際の業務を、 業務を、 あ、そう。 どういう感じですかね。 スペース指数とかでまだ管理されている部分はあるので、 そういうのの将来的には、 なんかデータとか、 そういうとこで進化に向けるといいよねっていうのを教えまわるみたいな。 そうですね。 僕もともとその辺めちゃくちゃアーカイブエンジニアではないんですけど、 AIの力でコストとかも下がってきた、 安全にもできる可能性もあるし、 なのでその辺はどんどん広げていきたいなと思ってます。 広げている最中ですね。 はい。ありがとうございます。 # MCP導入の裏側と、GitHubを活用した「スキル」共有の仕組み はい。というわけで、前回のチャプターではどうやって現場に入り込んでいったとか、 どういう風な設計でやっていったかみたいなところを話したんですけど、 このチャプターでは技術的なところを聞いていきたいなと思っています。 はい。 実際、このiの手、MCPを作ってみて技術的に大変だったところとか難しかったところはありますか? うーん、大変だったところ。 なんか、MCPを作る、そのこと自体ってそんなに難しくなくて、 すごくAIがやってくるって多いにあるんですけど、 MCPに何をさせるのかみたいな線引き、 それがスキルって言葉が前回の放送でも出てきたと思うんですけど、 スキルとツールの違いをもちろん理解していただくのも結構難しいし、 話も理解していただく必要もないかなと思うんですけど、 自分自身も理解するのちょっと難しくて、 ここは全然模索中ではあるんですけど、 スキルって結構AI向けのものだけど、 一方で人間も読めるようなものだなって思っていて、 一方でツールって、こういうツールだよっていうところだけAIに読ませて、 中身は普通にプログラミングされたものが動いているようなものなので、 ここの違いを理解するのが結構難しかったし、まだ難しいなという感じです。 どこをどうツールにしてどこをどうスキルにするかって、 切り分けが難しいっていう話がありますね。 NGSのライブで発表会でお話しました。 難しそうだなと思いました。 ここはどういう風に実際に作っていたんですか。 コミュニケーションを取りながら、こういうスキルにしたら使えるようになりますよね、便利になりますよね、 みたいな感じでコミュニケーションを取ってやっていたという感じ。 ここはあんまりコミュニケーションは、ツールを作る面ではやることを増やしたいっていう要望に対しては コミュニケーションを取っていましたけど、 スキルとツールの区分けどうしますかっていうところは、結構エンジニアの責任として進めているところがあって、 ちょっと言葉を選ぶんですけど、スキルは本当にどんどん作ってほしい。 セキュリティとか置いておいて、置いておかないですけど、 セキュリティとか大事にしつつ、どんどん作ってほしいなって思っていて、 一方でツールって結構ハウのところ、何をしたいかがスキルとしたら、 ツールはどうやってしたいことが叶えるかをコードとして書くところなので、 例えば誰がこういう想像をしましたかとかって、エンジニアとしては観測したりしたいじゃないですか、 エンジニアとしてじゃなくて、そういう非機能的なところってツールに込めるしかなくて、 そこはまだ完全に整備できていないかもしれないですけど、今も整備しながらやってます。 オブザーバビリティみたいな、観測できるようになって、 誰がどういうことをしたかっていうのを知れると改善もできますよね。 そうですね。遅いとかも結構あるので。 そこは考えてやっていったと思います。 実際そのツール作ったようだと、スキルを結構実装してもらうのも大変かなと思ったんですけど、 そこは割と各チームがガンガンスキルを作っていっている感じですかね。 そうですね。今はあんまり誰が広めてくれてるかわからないですけど、 要望ベースでツールを追加していっているので、チーム内でスキルをシェアしてもらったりとか、 あとはスキルをシェアする基盤とかも作っていて、 それで他の人のスキルを見たりとか改善したりとかもできるようにしているので、 最初の一人、それの電動車を作っちゃえば。 確かに。今スキルを共有する仕組みって言いましたけど、それどうなってるんですか。 スキルを共有する仕組みはクロードのプラグインという仕組みを使っていて、 GitHub上でスキルを管理することができるものです。 これは元々違う仕組みでスキルを共有していたんですけど、 クロードそのものにもスキルの共有機能とか、 組織用のスキル、この組織のアカウント全ての人が使えるスキルみたいな機能があるんですけど、 それだと編集したりとかちょっと難しい課題があったので、 ちょうどプラグインというものがGitHubと連携して使えるという話だったので、 それを使わせてもらって。 そのクロードプラグインを作るのは大変でした? 大変ではなかったですが、 それを作るためにGitHubを触れるツールを作りました。 なるほど、その非エンジニアでもGitHubを触れる仕組みがあるということですね。 プラグイン自体はすごく仕組みが単純なので、 あと要件とかも結構はっきりしているので、 それを作るためのツールとスキルを作って、 それを共有してみなさんに作ってもらうみたいな。 なるほど、確かに。 そうすればみんながスキルをそこにGitHubで追加していって、 それを共有できる仕組みができたってことですね。 ありがとうございます。 # これからは「なんとなく」を無くすフェーズ はい、では最後のシャフターでは 今後愛の手をどうしていきたいか こういう風にしていきたいみたいなものがあれば教えてください はい、さっきもちょっと話が出たんですけど オブザブミーティングの部分はまだ課題があるので 今どっちかというとどんどん使っていきましょうって方針で まだまだ広げていっていい時期だと思うんですが 各々の苦労でやったことって基本的には記録が残らないんですよね これはアンスロピックの思想としてそうやってるのか 契約プランの話とか そんなしない方がいいかなと思うんですけど 基本的にそこは追っかけられない部分もあるので どうしても俗人化とかもしちゃうなと思うので そういうところも含めて観測できるようにしていきたいですね 具体的には愛の手プラグインからMCPを呼び出すようにしてあげれば 分かるのか、そこ縛りを設けたりとか あとはちょっと確実性はあるか分からないですけど それ用のスキルを絶対デフォルトで呼び出すような 観測ログとかを出せるようなスキルを仕込むとか そういうところでどんどんオブザーVPは上げていきたいですね 確かに 今は結構みんな追加してもらうフェーズってことですね そうですね、今はどんどん使って これからの改善というかフォルドオブVPもそうです それにして改善ポイントも人のフィルターを通してしまうので なんとなく遅いとか、なんとなく繋がらないとか って言われても、なんて言われてもって言うか分からないですけど それだけを調査するにも当たりがつけづらかったりするので やっていきたいですね 他にありますか? 他にはもっとMCPどんどん作ってもらいたいなと思っていて 他のエンジニアにも そこは今整備とかも進めていて ちょっと仲間が増えそうな雰囲気もあるんですけど どんどんMCP作っていってもらって もしかしたらエンジニアの業務とかも スキルとかもちろん仲間行動とかは 人間があっては違うと思いますけど もしかしたらスキルとかで大体エリアもあるかもしれないので そういうところもどんどんみんなでチャレンジしていけたらいいかなと思います そうですね、今のおはぎさんのお聞きで 僕もガンガン作っていこうと思いました プレビューお待ちしてます じゃあ今回はこんな感じですかね 今日はありがとうございました 愛の手インタビューということで エンジニアのおはぎさんでした ありがとうございます