サイオステクノロジーのインターンシップに参加した、東京電機大学の森田です。 今回のハッカソン型インターンでは、 チーム開発の推進とアプリ実装を主導 しました。 本記事では、 AIをコアに組み込んだプロダクト開発の裏側 と、開発を通じて得た技術的・エンジニアリング的な学びを「開発」の軸から振り返ります。 自己紹介とサイオスを選んだ理由 自己紹介 日頃から開発環境の構築や自動化が好きで、最近は「 Claude Code 」を自分好みにカスタマイズすることに熱中しています。 特に力を入れたのが、ターミナル上で複数の AI モデル同士に議論をさせる「 AI 対話・ディベートシステム」の実装です。 1 つのモデルの出力を鵜呑みにせず、別の AI に反論させ、全員の意見が一致するまで議論を戦わせる仕組みを作ることで、出力精度の向上を実現しました。 また、趣味の一人旅では「計画を全く立てない」スタイルを好み、これは「計画を立てる時間をゼロにする」という今回のアプリ構想の原点にもなっています。 なぜ数ある企業からここ（サイオス）のインターンシップを選んだのか 選んだ決め手は、生成 AI を単なる「実験」にとどめず、 実際の開発プロセスやプロダクトの中に本気で組み込んでいる文化 を感じられた点です。 世の中に「 AI 活用」を掲げる企業は多く存在しますが、開発現場でどこまで本格運用されているかは外から見えにくいものがあります。サイオスはその姿勢が具体的であり、 生成AIを活用したチーム開発をハッカソン形式で丸ごと体験できる点 に強く惹かれました。 「AIを中心としたチーム開発」 と 「AR機能の実装」 という 2 つのテーマへの挑戦を目的に参加を決めました。   開発プロダクト「メタゼロ（ MetaZero ）」 「メタ学習時間」をゼロにするプロダクト 私たち A チームが開発したのは、大学生の 「メタ学習時間（学ぶ・解く以外の、探す・計画する・管理する時間）」をゼロに近づける モバイル Web アプリ 「メタゼロ（MetaZero）」 です。 ペルソナには、就活と専門科目に追われる大学 3 年生を設定しました。 大学では、課題や試験日程が複数の学内システムに分散しており、 全予定を一括管理できる画面が存在しない という状態も珍しくありません。私たちが構築した検証用環境で調べたところ、 13件の予定が計6サイト、30か所に分散して掲示されている状態 でした。 「メタゼロ」は、これら 6 つのサイトを自動巡回して 1 つの日程表に集約し、 AI との対話を通して 「いつ・何を・どれくらいやるか」を自動設計 します。最終的に 全13画面とAR実験機能 を実装しました。   開発基盤づくりと AI 駆動開発の実践 インターン期間中、私は 全238コミットのうち131コミットを担当 し、チーム全体の開発を前進させる立ち回りを意識しました。 初日に構築した「開発の土台」 まず初日に取り組んだのは、機能実装ではなく チームが安全かつ効率的に走れるためのインフラ整備 です。 Git フックと CI の構築： コミットメッセージ規約を自動で強制検知する仕組みを導入 pre-commit フック： 誤って API キーなどの秘密情報がリポジトリに混入するのを防ぐセキュリティチェックを自動化 ダミー大学サイト群の作成： スクレイピング処理の開発・テストを行うための練習用 Web 環境を迅速に用意   ルールを口頭で注意し合うのではなく、 「機械的に通らない仕組み」を CI/CD レベルで組み込む ことで、後半の開発スピードを飛躍的に高めることができました。 AI ツール（ Claude Code ）を活用したチームマネジメント リモート環境下での AI 駆動開発では、どうしても特定メンバーの環境へ負荷が集中する問題が発生します。 AI ツールへの連続指示によるトークン消費の偏りを防ぐため、 チーム全員のClaude Codeへ適切にタスクを分散配置 しました。状況に応じて負荷を平準化するアプローチは、 サイオスの行動指針である「 SIOS Values （ Respect ）」の実践 にも繋がったと感じています。 また、初期段階で Figma を用いたビジュアル共有を行い、全員の認識を揃えたことで、 リモート開発特有の手戻りを未然に防ぎました 。   開発の壁： LLM のパフォーマンスチューニングと「実測主義」 開発中で最も大きな壁となったのが、 Azure OpenAI 経由で利用していた gpt-5-nano の挙動不審と応答の不安定化 でした。 発生した障害 開発中盤、 AIチャット機能でタイムアウトが頻発し、空のレスポンスが返ってくる現象 が発生しました。アプリ側がこれを「 AI 接続失敗」と判定してしまい、 プロダクトのコア機能であるAI対話が機能不全に陥りました 。 直感による修正の失敗と「実測」による解決 当初は「タイムアウト時間を延ばす」「トークン上限を勘で増やす」といった応急処置を試みましたが、状況は改善しませんでした。そこで 思いつきのパラメータ変更を捨て、実際に API を呼び出して数値を計測・検証する地道なアプローチ に切り替えました。 max_completion_tokens を公式上限まで正確に引き上げる reasoning_effort のパラメータをユースケースごとに実測して調整する 高精度な採点処理： medium に設定して回答の精度を担保 タイムアウト回避・レスポンス優先の処理： low に落とし確実にレスポンスを返す   この経験から、 「LLMのパラメータを推測やネットの噂で決めてはならない。必ず自環境で実測して決定する」 というエンジニアリングにおける重要な原則を学びました。   プロの指摘から学んだ「 UX 」と「伝える技術」 成果発表後、プロのエンジニアやメンターの方々からいただいた指摘は、技術実装と同等に価値のあるものでした。 スライドに情報を詰め込みすぎている。画面の文字を減らし、言葉で深く伝えるべき UI（画面の見た目）だけでなく、UX（ユーザー体験）を設計すること このアプリによってユーザーの人生がどう変わるのかを Before / After で提示する 「動くものを作ること」と「その価値が相手に伝わること」は別物である と、身をもって痛感しました。 どれほど高度なロジックを組んでも、ユーザー視点の UX やプレゼンテーションが伴わなければ、プロダクトの価値は正しく届きません。   学びと今後の展望 個人開発から「チームの生産性を設計する」エンジニアへ 以前は Claude Code を個人の作業効率化ツールとして閉じた使い方をしていました。 しかし今回のハッカソンを通じ、 AI のカスタマイズや開発手順を GitHub 経由でチーム全体に共有することで、 全員のアウトプット品質が平準化され、底上げされること を実感しました。 エンジニアの本来の役割は「自分がコードを速く書くこと」だけではなく、 「チーム全体が良いプロダクトを打率高く作れる仕組み（環境・規約・ツールチェーン）を設計すること」 にあると、大きな意識の変化がありました。   今後の目標： AR 機能の高度化とチーム開発への挑戦 今回開発したメタゼロの機能の１つである AR 機能は、実はまだロードマップにおける「フェーズ 3 （数式の 3D 表示）」段階です。 今後は以下のロードマップに沿って拡張を進める予定です。 フェーズ 4 ： Σ や  ∫ などの複雑な記号への対応 フェーズ 5： 化学の 3D 分子構造モデルの表示（概念理解の補助） フェーズ 6： Meta Quest 3 や Xreal などの空間コンピューティングデバイスへの移植  「教科書の記号が頭の中で立体化しない」という学習の課題を完全に解決するため 、これからも技術的な挑戦を続けていきます。   また、残りの大学生活では意識的に多様なチーム開発へ飛び込み、今回の 10 日間で培った 「開発環境の標準化」と「LLMチューニングの実践力」 を武器に、エンジニアとしてのキャリアを築いていきます。   ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post 推測ではなく「実測」で勝負する。LLMパフォーマンスチューニングとCI/CD導入でチームの生産性を底上げした話 first appeared on SIOS Tech Lab .

はじめに さくらのナレッジ編集部の法林です。 2026年10月5日(月)にオンラインイベント「さくらの夕べ CoderDojoナイト」を開催しました。本記事ではこちらの模様をレポートします。 イベントの開催趣旨 Code […]

本ブログ記事は、株式会社インフキュリオン 菊田 慎一郎 様、向後 宗一郎 様、石原 幸治 様、佐々木 明良 様 および アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト 松原 武司 の共著です。 請求書のカード払いを実現するプラットフォーム「 Winvoice 」を提供する株式会社インフキュリオンは、2026 年 6 月、Winvoice 機能を AI エージェントから呼び出せるリモート MCP（Model Context Protocol) サーバーを公開しました。日本の請求書カード払い領域における MCP 対応サービスとしては初の事例です（インフキュリオン調べ）。 生成AI をめぐる技術は数か月で新しい要素が生まれ、トレンドも入れ替わり続けています。株式会社インフキュリオン様は「早く出して先行者になること」自体が競争力に直結すると考え、MCP 対応クライアントが普及し始めたこのタイミングにて、企画から公開までを約 1 か月で走り切ることを目標とし、それを実現されました。 本ブログ記事では、その短期間でのローンチを成立させたアーキテクチャ上の判断を軸に、課題、リモート MCP サーバー方式と Amazon Bedrock AgentCore ( AgentCore Runtime ) の選定理由、Fintech ならではのセキュリティ・統制設計、そして得られた価値を共有します。 実際に設計と実装を担当された株式会社インフキュリオンのエンジニアの方々に、以下をご説明いただきます。 株式会社インフキュリオン と 請求書カード払いプラットフォーム 「Winvoice」 課題：分断された経理業務と、AI 活用の壁 アーキテクチャの全体像 主なアーキテクチャ上の判断と今後の展望 株式会社インフキュリオン と 請求書カード払いプラットフォーム 「Winvoice」 株式会社インフキュリオンは 2006 年創業の Fintech 企業で、決済領域を中心に金融サービスプラットフォームを提供しています。「決済から、きのうの不可能を可能にする」をミッションに、ライセンス対応からカスタマーサクセスまでワンストップで支援する事業を展開しています。 Winvoice は、その中で「請求書カード払い」に特化したプラットフォームです。請求書を受領する側がカード払いに切り替えられる機能と、請求書を発行する側がカード決済オプションを追加できる機能を提供し、AI-OCR、承認ワークフロー、KYB (Know Your Business：企業確認) / KYC (Know Your Customer：顧客確認) 審査、3Dセキュア対応を備えています。SaaS 企業、金融機関、商社・卸といったプラットフォーマーが、自社サービスに請求・支払機能を組み込んで利用しています。 課題：分断された経理業務と、AI 活用の壁 Winvoice を利用する企業の経理現場では、請求書の受領から支払完了までの作業が複数のシステムにまたがって分断されていました。会計ソフト、経費精算、Winvoice、メール、各種ファイルといったソースを行き来する手作業が、月末月初の負担として残っていました。 一方で、AI を業務に取り入れたいというニーズは強く存在しました。しかし、ローカル環境のセットアップや API 連携の難易度が、非エンジニアの現場では着手の障壁になっていました。Claude Desktop をはじめとする MCP 対応クライアントが普及し始めたこのタイミングで、Winvoice 側からも MCP に応える側を準備することが、現場の経理担当者に AI 活用を届ける現実的な手段だと判断しました。 加えて、この判断には時間軸の制約もありました。MCP という規格そのものがまだ立ち上がり期にあり、対応クライアントの普及とともに主導権の所在が短期間で動く局面です。ここで早く実装を届けられるかどうかが、請求書カード払い領域での立ち位置を左右すると考え、私たちは短期リリースを前提にプロジェクトを設計しました。 請求書カード払いサービスで初の挑戦としての位置づけ 請求書カード払いは、決済という慎重さを必要とする領域です。インフキュリオン は、本プロジェクトを「業務効率化」だけでなく「Fintech サービスにおける AI エージェント連携のリファレンス事例」として位置づけました。 同時に、早く届けることに価値があるプロジェクトでもありました。生成 AI をめぐる技術と対応クライアントは数か月で様変わりし、この領域では先に出したサービスが事実上の参照点になります。そこで私たちは、企画から公開までを約 1 か月で完了させることを最初のマイルストーンとしました。 この短納期を現実的にしたのが、テックリードの菊田が描いた「既存資産の流用と AWS マネージドサービスの活用による MCP サーバー構築」という技術方針です。認証基盤には Winvoiceチームが本番運用してきた Amazon Cognito をそのまま使い、実行基盤にはチームが日常的に扱ってきた AWS、とりわけ Amazon Bedrock を中心とするマネージドサービスを選択する。ゼロから作り込むのではなく運用実績と習熟のある構成要素を組み合わせることで、限られた時間を Fintech として外せない統制の設計に集中させる— この方針を軸に、新卒入社の若手エンジニアが設計・実装の中核を担い、開発リードは入社 3 年目の佐々木が務めました。その具体的な構成は、次のアーキテクチャ全体像と設計判断で順に説明します。 また、本プロジェクトでは次の三項を同時に満たすことをゴールに置いています。 先行者として早期に届けること： 技術が数か月で入れ替わる中、企画から公開までを約 1 か月で実現する 非エンジニアの経理担当者・経営者にも届く体験 ：URL を 1 行設定するだけで AI エージェント側から Winvoice を呼び出すことができる状態 規制業種として求められる統制 ：認証・認可、テナント分離、監査ログ、最終承認における人の関与 アーキテクチャの全体像 システムは 3 層構成です。MCP クライアント層、Amazon Bedrock AgentCore Runtime 上で動作するリモート MCP サーバー層、そして既存の Winvoice バックエンド層です。MCP サーバーは Winvoice 既存の認証基盤と接続し、ユーザーが本来権限を持つ範囲のみを公開します。 設計判断 #1：リモート MCP サーバー方式の採用 MCP に対応する方式には、利用者がソースコードを取得して自分の端末で動かすローカル方式と、サーバー側でホストし利用者は URL を設定するだけで使えるリモート方式があります。 検証 や MVP (Minimum Viable Product) の段階では、ソースコードを GitHub などで配布するローカル方式が手軽で、実際に多くの事例がこの形を採用しています。Winvoice においても、社内での概念実証の段階ではこの方式で進めていました。 しかし Winvoice は、決済という利用者からの信頼が何よりの土台となる領域のサービスです。開発者以外の外部利用者へ正式に提供する際には、ローカル方式のままでは、この信頼を支えきれないと判断しました。ソースコードを公開すること自体が攻撃の起点になりうること、開発者でなければ安全に導入・運用できないこと、機能を更新するたびに各利用者の端末へ配布し直さなければならないことは、いずれも決済サービスに求められる安全性と一貫した運用を損ないます。 そこで インフキュリオンでは、サーバー側で認証・認可・監査を一元的に管理でき、利用者にはソースの管理も環境構築も求めず、接続も HTTPS だけで完結する、より信頼性と安全性の高いリモート方式を採用しました。この方式では、機能改善もサーバー側の反映だけで全利用者へ届けられるため、立ち上がり期の規格を扱う上で欠かせない「出した後に速く直せること」も同時に満たせます。 リモート MCP サーバー方式は、生成 AI を業務に組み込もうとする多くの企業で共通の論点になります。利用者側の環境構築を不要にできるため、配布コスト・サポートコストを抑えながら、対象ユーザー層を一気に広げられる点が事業判断としても有効です。Fintech のように非エンジニアのユーザーが多い業界では、特に効果が大きいアプローチです。 設計判断 #2：リモートMCP採用にあたってのAWSアーキテクチャの検討 リモート MCP サーバーの実行基盤は、複数の構成案を検討し、タイムアウト仕様の調査と PoC での検証を経て絞り込みました。壁になったのは、Winvoiceの提供機能に含まれる最大10分程度を見込む処理においても、その進行状況をMCP の Streamable HTTP プロトコルにおいてサーバーサイドからクライアントに状況をSSE (Server-Sent Events) で通知可能とすることでした。 AWS App Runner や、 Amazon CloudFront + AWS Lambda 構成も候補に挙がりましたが、この観点から除外しました。 最終的に Amazon Elastic Container Service (ECS) と Amazon Bedrock AgentCore Runtime が候補として残りましたが、AgentCore Runtime の採用を決定しました。採用の決め手となったのは以下の 3点 です。 MCP プロトコルのサポート ：SSE ストリーミングに最大 60 分対応し、ハートビートのような回避策なしに長時間接続要件を満たすことができます。 ステートフルなセッションを標準機能で実現 ：セッションごとに専用の マイクロ仮想マシン (microVM) が割り当てられ、セッション継続性とテナント間の分離を仕組みで担保できます。 運用負荷とコストの最小化 ：クラスタ管理・パッチ適用が不要で、セッション期間中の CPU・メモリの秒単位従量課金、I/O 待機中は CPU 無課金のため、常時稼働構成を避けることができます。 また、AgentCore Runtime の microVM から Amazon S3 や Amazon Cognito などの AWS サービスへアクセスする経路には、VPC ネットワークモード と VPC エンドポイント（ AWS PrivateLink ）を採用しました。これにより、AWS内にトラフィックが留まるセキュアな通信経路を確立しています。 さらに、既存の Winvoice 本番環境とは VPC 自体を完全に分離する設計としました。万が一、リモート MCP サーバーが設計上意図しない動作を行うような事態が発生した場合でも、その影響を最小限に止め、Winvoice 側が持つ機密情報への不正アクセスを未然に確実に防ぐ「多層防御」のアーキテクチャを実現しています。 設計判断 #3：認証・認可 ― 既存の認証基盤を無改修で接続する AI エージェントという新しい入口を設ける上で、認証と認可において、次の 3つの問い に答える必要がありました。 認証 ：OAuth 2.1 + PKCE と Protected Resource Metadata（RFC 9728）によるディスカバリを求める MCP クライアントを、既存の認証基盤とどう繋ぐか アウトバウンド ：MCP サーバーは、どのような権限で Winvoice API を呼び出すか 認可 ：MCP 連携を、誰にどう開放するか いずれのポイントでも、稼働中の決済サービスである点を鑑み、「既存アプリケーションには極力手を加えない」ことを共通の前提 (制約) としました。採用した構成の全体像は次のとおりです。 認証：Hub & Spoke 型の Cognito フェデレーション MCP クライアントはブラウザーリダイレクト型の OAuth フローを前提としますが、Winvoice の既存認証はこれに対応していません。加えて、Winvoice はプラットフォーマーごとにテナントを分離したマルチテナント構成で、Cognito ユーザープール もテナント別に分かれています。そこで、MCP 専用の Cognito ユーザープール（Hub）を新設し、テナント別の既存ユーザープール（Spoke）を OIDC IDプロバイダー(IdP) としてフェデレーションする構成を採用しました（図 の ①・②）。ポイントは次の 3 点です。 シンプルな接続体験 ：MCP クライアントからは OAuth 2.1 + PKCE に対応した認可サーバーが 1 つ見えるだけです。ユーザーは既存の Winvoice アカウントをそのまま使ってサインインでき、新たなアカウント発行やパスワード管理は不要です。 既存基盤は無改修 ：既存の ユーザープール は OIDC IdP として参照されるだけで、稼働中のアプリケーションに影響を与えません。 自前実装の最小化 ：トークンの検証は Bedrock AgentCore Identity の インバウンド認証（ カスタムJWTオーソライザー設定 ）に委譲し（図の③）、独自実装部はディスカバリ用メタデータ応答の検証などの薄いレイヤーのみです。 アウトバウンド：「AI に権限を渡さない」トークン設計 MCP サーバーが Winvoice API を呼び出す際は、AgentCore Identity の機能である Token Vault が提供する 3-Legged OAuth により、ユーザー本人の同意を経て取得した本人のトークンを使用します（図の④・⑤）。Winvoice API 側からは MCP 経由のアクセスを通常のユーザーアクセスと同一に扱えるため、既存の認可・テナント分離・監査の仕組みがそのまま最終防壁として機能します。AI エージェント経由でも、権限の主体は常に人 (ユーザー) のままという設計原則です。 認可：二段構えの許可リスト 決済に関わるサービスとして全ユーザーへの一斉開放は行わず、「誰に AI 連携を許すか」を利用企業自身がガバナンスできる形にしています。 層 操作者 内容 ① 法人単位の利用設定 利用企業の管理者 利用規約に同意して MCP 連携を有効化。無効化すれば配下ユーザーの利用許可も一括で解除 ② ユーザー単位の許可リスト 利用企業の管理者 有効化した法人の中でも、明示的に許可したユーザーのみが利用可能 この二段構えにより、β版としての段階的な開放にも、問題発生時の即時取り消しにも、同じ仕組みで対応できます。許可リストの正本は Cognito ユーザープール の「 グループ 」に配置し、トークンに含まれるグループ情報で判定することで、ここでも既存アプリケーションの無改修と独自実装する範囲の最小化を徹底しました。 Winvoice 今後の展望 本リリースは、Winvoice における AI エージェント連携の第一歩です。株式会社インフキュリオン は 以下の方向で取り組みを検討し、アマゾン ウェブ サービス ジャパン は、そのご支援を継続します。 会計ソフト・経費精算サービスとの横断連携を MCP 越しに実現し、AI エージェントを経理業務のハブにする 既存機能や外部請求書取込といった機能を、MCP ツールとして順次拡張する Claude 以外の MCP 対応クライアントへの対応拡大など、ベーシック機能を拡充する 蓄積した取引データと AI を組み合わせ、資金ショート予測といった先回りの提案へ踏み込む まとめ Winvoice はリモート MCP サーバー方式により、URL 設定のみで AI エージェントから請求書カード払い業務を呼び出せる体験を実現しました。 既存の Amazon Cognito と、チームが習熟していた Amazon Bedrock を中心とする AWS 環境を活かしたことが、企画から公開まで約 1 か月という短納期を後押ししました。 Amazon Bedrock AgentCore Runtime のセッション分離・認証認可の統合により、Fintech に求められる統制と AI 活用を両立しました。 最終承認は人間が画面で実施するヒューマンインザループ設計により、規制業種としての安全性を担保しました。 本アプローチは、AIエージェント連携を業務システムへ組み込む際の、Fintech 領域での参考事例の1つとなります。 著者について 菊田 慎一郎 (株式会社インフキュリオン) Winvoice 部 テックリード 前職ではソフトウェアエンジニアとして EC サイトのリプレイスなどを担当。 2025 年 4 月にインフキュリオンに中途入社し、Winvoice のテックリードとしてアプリケーション開発に従事。本プロジェクトでは、約 1 か月での公開を現実にするため「既存資産の流用と AWS マネージドサービスの活用」という技術方針を描き、テックリードとして設計・実装に伴走。若手エンジニアが中核を担う体制を支えた。 向後 宗一郎 (株式会社インフキュリオン) Winvoice 部 ソフトウェアエンジニア 2021 年新卒入社。Wallet Station でフロントエンドテックリードを経てプロダクトアーキテクトを務め、次世代アーキテクチャの構想・設計を主導。2026 年より Winvoice のスクラムチームリーダーとしてチームに合流。本プロジェクトでは認証認可設計・アーキテクチャレビュー・実装支援を横断的に担当。 石原 幸治 (株式会社インフキュリオン) プロダクトマネジメント部/Winvoice 部（兼務）インフラエンジニア 前職では VMware を中心としたオンプレ基盤の設計・構築・運用に加え、オンプレ基盤と外部ネットワーク間の接続設計・構築を担当。2026 年 2 月にインフキュリオンに中途入社し、Winvoice の AWS インフラ基盤の設計・構築・運用と Terraform による IaC 管理を担当する。本プロジェクトではリモート MCP サーバーのインフラ設計・構築を担当。 佐々木 明良 (株式会社インフキュリオン) Winvoice部 ソフトウェアエンジニア 2024年新卒入社。請求書AI-OCR機能の開発やAI審査支援など、AIの業務適用領域を主に担当。本プロジェクトでは開発リード兼プロジェクト推進として、要件定義からステークホルダーとの調整、進捗管理、MCPサーバのアプリ実装までを幅広く担当。 松原 武司 (アマゾン ウェブ サービス ジャパン合同会社) シニア ソリューションアーキテクト 決済領域のお客様の AWS 活用を支援。本プロジェクトでは、リモート MCP サーバーのアーキテクチャ検討と Amazon Bedrock AgentCore Runtime 採用判断をご支援・伴走。