# チャプター 1 TOMOとKEY君のボイコード Voicing Engineerの声と出会えるチャンネル、ボイコード このチャンネルでは、Voicing Engineerの日々の活動をお届けしています。 はい、なんかこの組み合わせは久々な気がするな。 そうですね。 なんか平日版は、まあなんか固定メンバーなんで、あれですけど 休日の方は、週末版の方は結構入れ替わりだから。 そうですね。 一周するのにだいぶ時間かかるし。 そう、なんかちょっと久々だなっていうか。 KEY君はもともとチーム一緒だったから、話す機会がめっちゃ多かったけど 最近はちょっと減ったかなみたいな。朝会が一応ね、あるって。 その時に、ちょっと最近は喋ってるけど。 時期も近いですしね。 そうそうそうそう。確かに。 名残ですね。 機会もある。 そうそうそう。確かに。 じゃあ、今日は愛の手の話しますか。 はい、愛の手。 愛の手の話ってあれか。 ブログとかでは知ってるけど、ボイコードを喋ったっけ。 あ、あれかな。 前に、なんか愛の手を作った時とかに、なんか話してたかな。 ちょっと話した気がしますね。 そうですよね。 愛の手って何ですか。 愛の手。愛の手とは。 愛の手とは。 あれ?社内用のMCPのツールですよね。 毎日朝会やってるのは、愛の手っていうMCPの関連の開発をしているのが僕だったりとか。 キー君はそこに参加してくれてるみたいな感じで。 最近そのやり取りをちょこちょこしたりとかしてるんで。 そうですね。一応MCPについても。 確かに。MCPって何かよくわかんないな。 オーシャルコンテキストプロトコルですね。 AIがうまく動いてもらえるように、AIにツールを使えるようにするみたいな。 それを、おいしいでは愛の手と呼ばれている。 愛の手のMCPサーバーを作って、うまいことやってもらってると。 これちょこちょこある一般的な質問として、APAとどう違うんですか?みたいな話もありますよね。 確かにそうですね。 まあ、あれですよね。JSONでしたっけ?どう忘れてしまったけど。 やり取りがJSONスキンマー的な感じだから、やり取りしやすいのはありますよね。 確かに。それもあるな。 まあ、APAで叩くこともできると思うんですけどね。 まあ、ただあれですよね。一人一人のマクロードでAPAを叩いてみたいな何かが、それぞれでやらなきゃいけないみたいなところがあったりするから。 自動でツールを読み込んでくれて結構してくれるみたいなところがメイントですね。 この制御、どれくらい何をしたいのかにもよると思うんですけど、 全体としてというかツールとしてこういうふうに呼び出してほしいとか、一定の制約をつけたりとかしたいときとかを一元管理できるというか、そういう側面もあるのかなと思いつつ。 確かにそうですね。 最近だとあれですよね。VSTには今デザイントークンとかを整備しようとしていて、それをつなぐことを友さんがやっていて。 会社の組織のスキルとして、みんながそれぞれの部署で使いたいスキルを作ったりとかしてるんですけど、 そのときにこのデザインシステムをGitHubで管理されているんだけど、そこのどういうデザインにしてくださいっていうものがGit管理されてるんだけど、 スキルでそれを直接読めなくてベタ書きするみたいな感じになっちゃって。 AIがあるから基本ベタ書きでもそんな困らないかなっていう気持ちはありつつ、 せっかくGitで管理されていてそこがAIの言葉で言うと製本と言われるやつがあって、 なのにそれのコピーを毎回更新があるたびに作業しなきゃいけないっていうのがちょっと扱いづらいなというか、 どこかのリポジトリの中身を参照したいみたいなことって全然ありそうだなっていう感じがしてきたんで、 そこら辺をある程度更新があったら自動でプルリク作ってそれをマージしてあげればいいみたいな仕組みを最近ちょっと1個入れましたね。 いいですね。 この辺とかもうちょっと楽にできたらいいなっていうか、ありそうな気がして、 現段階でいいプラクティスがなかなか見つけられなくて、 いろいろキー君とも話したんですけど、これぐらいかみたいな。 そうですね。 あそこで動画できてると結構将来というか、更新は楽だと思うので。 そうですね。そこのところの基盤を作ってみたいな感じにはしててので、最近ちょっと1個改善しましたね。 個人的にちょっと最近いろいろ意識を高めてるというか、APIというかサーバー、アプリケーションですよね。 アプリケーションを作るときにどう作るべきなんだっけみたいな、そこのベストプラクティス。 特にサーバーサイドに近いというか、サーバーサイドじゃないですかあれは。 なのでサーバーの開発でそもそもどういうふうに作っていくのがいいんだっけみたいなところを最近ちょっと個人的に勉強してて。 いろんな観点あるとは思うんですけど、やっぱり外部のデータをちゃんとインプットというかリクエストできたものをちゃんと正しいかどうかを検証して、 例えば仮にどこか別のサーバー、外部だったり内部のサーバーどっちでもいいんですけど、サーバーの結果を受け取ってそれを加工して最終クライアントに返すみたいなことをやってるんであれば、 外部のAPIレスポンスをちゃんとパースするっていう、そこをちゃんとやらないと何かちょっと想定外のことが起きたときに変な挙動になったりとか、 最悪ちょっとまずい状態になるというかいうこともあるんじゃないかなと思うんで、 ソフトウェアとしてそこをしっかり守っていくみたいなところで、ちゃんと外部から受け取ったものをパースして、 パースがちゃんと通るものというか想定したものがちゃんと通るだけアプリケーション内で扱えるようにするみたいなところを個人的にガイドライン引いてみたいなのを愛の手でやろうとしてますね。 いいですね、そういう片付けも大事ですよね。 その辺は別に速報性がある何かというわけではないんですけど、長期的にみんなが開発していく中でそこら辺のルールが縄々と、 いろんなところにそういうフィギュアが出やすくなっちゃうから、そこら辺のルールメイキングはある程度知っておいた方がいいんじゃないかなみたいなところで、 それも自前で自分たちで行動というか、いわゆる社林の再発明的な何かでやるんじゃなくて、 信頼できるライブラリとかを必要に応じて使ったりとかして、検証だったりパースとかはやった方が結果的にいいんじゃないかなみたいなところがあって、 そこら辺はちょっと最近気になってやってますね。 いいですね。 今日ちょうどそれに近い話ありましたよね。 そうですね、ありましたね。 やっぱりサーバーですかね。 誰がリクエストするか分からないからどういうやつを、AIなんてもしかしたら変なことするかもしれないっていう前提でちゃんと処理されるべきだなみたいな感じで、 本当にゼロトラストじゃないですけど、そんなことをしてますね。 # チャプター 2 最近はそんな感じで、ちょっとずつ改善を入れていったりはするんですけど 日々悩んでいるのが、どこまでをMCPの付き元をするかは結構いつも悩んでいるというか 今日も同じチームのメンバーがツールの追加をしてくれたんですけど それで、これは違うんじゃないかなと思いつつ どこまでをMCPの役割とするんだっけみたいなところとかは結構悩ましいなみたいなところはあるんですけど 確かに、そうですよね。難しいのは業務効率化をするために AIを使ってMCPでいろんなツールを呼び出すみたいなことをやってるわけじゃないですか それをするために逆に複雑になっちゃったり それでいいんだっけみたいなことになる可能性があって 今後の発展性も考えたりすると、そこは難しいですよね ツールを特定の用途で開発しちゃうと、やっぱり汎用性に欠けたりするから とはいえ、その複雑性をMCPサーバーを単純にAPIを叩く軽量なラッパーだとみなすと 使う人がちょっと注意しなきゃいけないというか ある程度どういう風に使わなきゃいけないんだっけみたいなところとかを あまりにも意識しなきゃいけないとそれは大変なんだろうなみたいなところとかも 今日ちょっと話したりとかしてて、さち加減ちょっとむずいなというか AIに依頼する側とAIがどうそれを読み取って使うかを考えないといけないから そこはちょっとむずいなっていうのはありますよね しかもツールって結構汎用的なことが多いから 他の人はこういう使い方をするかもしれないみたいな この人たちはこういう使い方をするけどみたいな感じで 複数の使い方が存在し得たりとかした場合に それぞれでスキル作って管理するのはちょっと大変だなみたいなところとかも 全く目的が違ってたらいいんだけど 共通する部分が何か含まれてるんだったら それをそれぞれ知っていないといけない使う側が スキルとして定義するってことを知ってないといけない構造は 確かにちょっと嫌だなみたいなところとかも 考えながら日々どう設計したらいいのかなみたいなところは 試行錯誤というか そこの設計を考えることが我々のまだいる未来か AIに任せられないところか そうだとしても 結局AIとやり取りしてどういう設計をするかを決めるわけなんだけど 最終ね AIと喋ってるだけと言えばだけになってしまいますが そこは結構自分で考えてみたいなところとかは 結構知ってるかなっていう 個人的な思想としては 割と軽量なラッパーとして振る舞うようにしたいみたいなところがあるんで 基本的にどう使うかはあんま書きたくないみたいな感じでは 個人的には思ってるんですけど たまになんか書いた方がいいんじゃないですかみたいな意見とかがあって 悩みながらどっちがいいんだろうというのを考えたりはしてますけど 確かにそこの塩梅はやっぱり難しいですよね 今後モデルとかが進化していってもそういうのもありそうな気がする 僕たちというか人間がAIに主情を出すという構造が変わらない限りは そこのMCPの設計は大事なのかなと思います MCPの開発っていうとかなりAIに特化してるイメージもありますけど 意外と普通のサーバーを作るのとあんま変わんないなという感覚は 個人的にはあったりはして さっきも言ってましたけど 結局クライアントで使う人がいて その人がどう使うか考えた上で クライアント設計してサーバー設計するわけ それは同じです そこら辺は同じで唯一違うのは AIはコンテキスト量が限られてるから 大量のデータとかバーンと返しちゃうとちょっとやばいんだろうなみたいなところがあって そこら辺のトークンの量とかは調整しなきゃいけないかなとか あったりすると思うんですけど 確かにいろいろ考えることありますね 結構だから最近はそこら辺をちょっと勉強しながら これ確かに考えなきゃいけないなとかっていうのを 自分の中でも整理しながらではありますけど サーバーは結局あれですよね ユースケースによって結構ベストプラクティスというか 別なものが違ってくるから やっぱりそこは自分たちで頭を悩ませる部分なのかなと そこら辺はなんかやっぱ最近 むしろそこぐらいかな 物を書いてるって言われるけど 別に書いてるわけないしなみたいな感じではあるんで 基本そこかな 確かに実装は映画見で そこっちにちょっと間違ってたらそこを見るぐらい スキッチするぐらいで これ全然愛の手関係ないんですけど ついでに話そうかなと思ったのが 僕は今って 人によっては全然違う開発の仕方をしてる人もいると思うんですけど 今って基本僕はこういうことをしたいってことを伝えて それに基づいて実装が出てきて その実装を確認するみたいな感じなんですけど 今現状だとその往復があるんですよ ここはこう直して、ここはこう直してみたいな それがもうちょっと嫌だなってなってて 確定した何かのインプットがあったら アウトプットがほぼある程度の水準で出てくる何かを 作りたいなと思ってるんだけど 何が確定してないから 僕がお願いしたアウトプットは不安定なのかなみたいなのを ちょっと最近は考えていて このチャットのやり取りなくしたいなみたいな 最初からもう何か出てくるものが ある程度想像ついている状態にしたいなみたいなのは 何かちょっと考えてて やっぱスキルとかになるんですかね そうすると自分の思い描いたものをドキュメントにして 君に取ってもらうという だから今めっちゃ難しいなと思ってるのが 自分がどうして欲しいのかを ちゃんとあらかじめ言語化しなきゃいけないという大変さ 見せられたらそれがいいか悪いかというか 受け入れられるかどうかは自分の中で判別はつくんですけど それが最初から別にあるという感じではないというか 出されたらこれちょっとおかしくないみたいな感じで思うんですけど 最初から基準としてちゃんと自分の中で体系的に 使われてるわけじゃないから そこのインプットを確定させるのが結構むずいなっていうのは 最近 どっちかというとAIの使い方の部分にはなると思うんですけど 確かに僕は前やってた時のやつとか 結構レビューで指摘してる 自分が指摘してる項目をランキングにしてくださいって 見たりはしてました こういうとこが気になってるんだみたいな それが分かったりしてめっちゃ面白いです それで解決するというよりは抽象的なのかなって 今聞いてたもんじゃないですか それである程度つぶせると思うんですけど レビューのコメントでAIに書いてもらったやつとかあるから それは違うからなみたいなやつもあるから そこら辺の線引きというか 絶対あるはずなんだけど それを自分の中でまだきちんと言語化ができてない部分が結構あるから そんなのあったりしますかね 今週はこんなところですかね 今週はこんなところで終わりたいと思います ありがとうございます 次はどんな声とつながりますか 引き続きVCでお楽しみください