SUZURI・minne事業部の渡辺(@ae14watanabe)です。2026年4月にシニアエンジニアとなりました。自己紹介を兼ねてこれまでの自分の取り組みを簡単に紹介します。その上で、これから何をしていくのかを述べ、所信表明とします。
これまで：サービスがAIを使う
私は自身の専門領域を「AIが関わるサービスの開発」とし、これまでSUZURI byGMOペパボにおいて、AI（LLMをはじめとする機械学習モデル）を導入した機能の開発を複数行ってきました。具体的な取り組みについてはこちらの資料にまとめていますが、一例を挙げると、商品の規約違反チェックをAIで自動化するプロジェクトをリードしてきました。
AIを導入した機能開発と、そうでない開発の根本的な違いは、不確実性の有無にあります。従来のソフトウェアは書いた通りに動きます。バグがなければ期待通りの結果を決定的に返します。一方でAIは、入力のわずかな違いで出力が変わりうる、複雑な判断を求められるほど完璧な結果は期待できない、といった性質があり、不確実性が常につきまといます。この不確実性をハンドリングすることが自分の仕事だと考えています。
ハンドリングとしてやってきたことは大きく2つあります。1つ目はAIへの入力を設計し、評価し、改善するサイクルを回すことです。規約違反チェックの例でいえば、違反ジャンルを網羅したデータセットを構築してAIの判断を定量評価しました。さらに、CSチームが現場で見つけた誤判定のフィードバックも踏まえて改善サイクルを回してきました。2つ目は、AIの誤りを許容できるフローの構築です。AIは間違える前提で、ユーザ・サービス・運営者それぞれのレイヤーで誤りを吸収できる仕組みを設計してきました。
これから：AIにサービスを使ってもらう
しかし最近、自分が「AIが関わるサービス」をかなり狭く捉えていたのではないか、と思うようになりました。
自分がやってきたのは「サービスがAIを使うこと」でした。構造としては「ユーザ ↔ サービス ↔ AI」——サービスがAIを呼び出し、その結果をサービスが受け取ってユーザに届ける形です。
一方で、もうひとつの構造があります。「ユーザ ↔ AI ↔ サービス」——AIエージェントがMCPやCLIを通じてサービスをツールとして使う形です。
たとえば今、Claude Codeのようなコーディングエージェントは、CLIやMCPを通じてさまざまなサービスを日常的に使っています。こういったエージェントにサービスを使ってもらうことも、「AIが関わるサービスの開発」です。エージェントが単一のタスクにとどまらず複数のサービスを組み合わせて作業を遂行するようになりつつある今、こちらの構造の重要性はより増していくと考えています。
前者と後者の構造では、不確実性のハンドリングの手段が変わります。前者ではAIの出力をサービス側で受け取れるため、前述の誤りを含む想定でのフロー構築など、出力側のハンドリングを行うことができました。これに対して後者では、AIの出力はユーザに向かい、サービス側からは見えません。出力を制御できないなら、入力の設計がハンドリングのほぼ全てになります。
だからこそ、ツールとしてのレスポンスやスキーマの設計が重要となります。エージェントに実際にツールを使わせ、どう振る舞うかを観測し、改善していく。SUZURI byGMOペパボでやってきたことと地続きですが、まだ誰も正解を知らない領域だと感じています。これまでやってきたことをより洗練させてやっていかねばと思っています。
ペパボでは、カラーミーショップのAIコネクターやムームードメインのMCPサーバーなど、既存サービスにおけるこの「ユーザ ↔ AI ↔ サービス」構造への取り組みがすでに始まっています。これらは既存サービスの延長線上にある取り組みで、もちろん重要です。しかしこれからは、この構造をネイティブとする新しいサービスに挑戦することで、既存サービスの延長線上では届かない価値を届けられると考えています。そこを、自分が先頭で実践していく。これがシニアエンジニアとしての自分の所信です。
