経歴・職務経歴
川越 航太
Kota Kawagoe — Software Engineer
自律型AIエージェントの社会実装を目指すソフトウェアエンジニア。ハッカソン速度のプロトタイピングから、動かし続ける本番運用までを一人で担います。
志望：AIアプリケーションエンジニア / バックエンドシステム開発
32.6%
WebArena Shopping タスク成功率（Browser-Agent）
N=187 ／ 最大ステップ40 ／ リトライ4回 ／ 同一プロンプト
1.7×
長期・短期メモリ最適化によるタスク成功率の改善
マルチエージェント基盤／NCSP’26にて発表
70/1800
松尾研 LLM講座コンペティション — 上位4%
LoRA SFT + DPO によるファインチューニング、2024–2025
2サービス
自分で作り、今も運用を続けているサービス
chatcore-ai.com · fs-qr.net
サマリー
Summary私の強みは、AI・デザイン・英語の3つを高い次元で組み合わせられることです。技術を形にするだけでなく、それを必要としている人に伝えるところまでを一人で担えます。
エンジニアリングの先へ
コードを書くこと自体よりも、その先にあるビジネスを考えられることに価値があると考えています。世の中のどこに本当の需要があるのか、サービスの運用・維持にどれだけのコストがかかるのか、それをどう成立するプロダクトへ落とし込むか。だからこそゼロからの新規事業の立ち上げを得意とし、素早いプロトタイピングから安定した本番運用までを一気通貫で担えます。現在も稼働を続けているサービスが、その実績です。
実際に手を動かしてきたこと
Browser-AgentやIoT-Agentなどを統合したマルチエージェント・オーケストレーションシステムを開発し、Web上で完結せずハードウェアを介して実世界にフィードバックする仕組みまで作りました。長期・短期メモリの扱いを最適化してタスク成功率を1.7倍に改善し、その成果を国際会議NCSP’26（ハワイ）で英語で口頭発表しています。
現在とこれから
Direction修士課程では、Memory・Skill・Tool・Agent という4種類のAIリソースを、共通の形式で登録・検索・選択・実行できる汎用AIエージェント基盤を研究しています。
性質の異なるこれらのリソースを統一的に管理し、タスクに応じて必要な組み合わせを自動で選び、安全性と権限を確認したうえで実行します。さらにタスク計画、状態管理、人間による承認、失敗復旧、監査ログまでを一元化することで、特定のLLMや用途に依存しない「AIエージェント版のOSカーネル」の実現を目指しています。
並行して、さまざまな種類のLLMを活用したWebアプリケーションの開発と、RAGを用いた検索システムの構築、ReActアーキテクチャの実装、メモリ機能の更新によるパーソナライゼーションなど、エージェント構造の研究・開発を続けています。ブラウザ操作エージェント、IoTエージェント、そしてそれらを統合するオーケストレーションシステムも、同じ線の上にあります。
これらの取り組みを通して目指しているのは、AIエージェントを社会実装し、人々の余暇時間を増やして、人と人とのコミュニケーションがより活発になる社会をつくることです。作ることと同じくらい、動かし続けることにこだわっているのはこのためです。
これまでの流れ
Timeline- 20214月 神奈川工科大学 情報学部 情報ネットワークコミュニケーション学科 入学。
- 20236月 留学のため1年間休学し、University of North Alabama へ交換留学。成績優秀者（Dean’s List）に選出され、AI授業の最終プロジェクトでクラス1位。
- 20245月 交換留学を修了して帰国、復学。
- 2024–2025 松尾研究室の各プログラムに参加。LLM講座コンペティションで上位4%（1,800人中70位）。
- 20254月 Manaable株式会社との共同研究を開始。RAGシステム最適化のプロジェクトリードを担当。
- 20259月 共同研究の成果をFIT 2025にて発表。成果をもとに特許を共同出願。
- 20263月 ハワイ・ホノルルの国際会議NCSP’26で英語口頭発表。神奈川工科大学を卒業。
- 20264月 慶應義塾大学大学院 政策・メディア研究科 サイバーインフォマティクス専攻 修士課程に進学。汎用AIエージェント基盤の研究に着手。
稼働中のサービス
Live ServicesChatCore-AI
運用中
メール認証付きのAIチャットと、ユーザー間でプロンプトを共有・検索できる仕組み。FastAPIとNext.jsで構築し、nginx配下のBlue-Greenデプロイで運用しています。
chatcore-ai.comFS-QR
運用中
セルフホスト型のファイル／メモ共有ツール。QRによる即時共有、合言葉付きのグループ共有、WebSocketでリアルタイムに同期する共有ノートを備えています。
fs-qr.net経歴
ExperienceManaable株式会社
共同研究員 / プロジェクトリーダー
- RAGシステム最適化の共同研究をリード。Q&Aデータの個人情報マスキング、連続するマスキング済みデータを複数LLMで比較する検証、RAG用データ保存形式の検討という3ステップに分け、それぞれ1人ずつが担当。自分はプロジェクトリードとして、これまでのRAGチャット開発の経験を活かし、3人それぞれの実装・設計・検証方針を横断的にサポートした。GitHubでコードと実験内容をバージョン管理し、各担当の変更を確認しながらチーム全体の実装方針をそろえた。
- 特許 本研究の成果をもとに特許を共同出願（出願中）。
- 発表 FIT 2025（第24回情報科学技術フォーラム）にて成果を発表し、回答精度の向上を実証。 → 論文（PDF） / 講演プログラム
Manaable株式会社
ソフトウェアエンジニアインターン
- 共同研究の終了後、その成果を実際のプロダクトに落とし込むためインターンとして参加。カスタマーサポートチーム向けの社内AIエージェントシステムをAWS上で設計・開発した。
- Jira上に蓄積された操作マニュアルをMarkdown形式に変換・構造化し、BM25とベクトル検索を組み合わせたハイブリッド検索RAGパイプラインを構築。gpt-5.1-miniを用いたプロンプト設計を重ね、チャットUIから自然言語で回答できるようにした。
- 単純なRAGチャットにとどまらず、Jira API連携による問い合わせチケットの自動起票、RAG回答に加えた顧客向けメール文案の自動生成まで拡張したカスタマーサポートエージェントとして開発。
- 実際にカスタマーサポートチームに使ってもらいながら毎日ディスカッションを重ね、要件定義から応答品質の改善までを反復的に実施。
- 機能ごとに
feature/*/fix/*ブランチを切って開発し、変更内容を明記したPull Requestを通じてマージ。レビュアーとしてもチームメンバーのPRに構造的なフィードバックを行い、コード品質と実装方針の一貫性を担保した。
チームでの働き方
Teamworkメンバーの手を奪わず、方針を支える
共同研究では作業を3ステップに分け、それぞれを1人ずつが担当しました。プロジェクトリードとして各ステップを巻き取るのではなく、これまでのRAGチャット開発の経験を各メンバーの実装・設計・検証方針に当て、3つの担当が同じ方向を向くように揃えました。
判断と実験をリポジトリに残す
コードだけでなく実験内容もGitHubでバージョン管理し、各担当の変更を確認しました。何を試して、なぜそう決めたのかが一箇所に残っていることが、3人の結果を比較できる前提になります。
レビューされる側だけでなく、する側にも立つ
インターンでは機能ごとに feature/* / fix/* ブランチを切り、変更内容を明記したPull Requestを通じてマージしました。レビュアーとしてもチームメンバーのPRに構造的なフィードバックを行い、コード品質と実装方針の一貫性を担保しています。
使う人の隣で作る
カスタマーサポート向けのエージェントは、実際にチームに使ってもらいながら毎日ディスカッションを重ね、要件定義から応答品質の改善までを反復しました。要望と実際に必要なものとのずれは、この距離でないと読み取れません。
主要プロジェクト
ProjectsBrowser-Agent
Web UI付きブラウザ自動化エージェント
2025年12月 – 2026年3月個人開発
browser_useをFastAPIとnoVNCでラップした、Web UI付きのブラウザ自動化エージェント。自然言語による操作とWebArenaベンチマーク評価に対応。WebArena Shoppingタスク成功率は32.6%（N=187、最大ステップ数40、リトライ4回、同一プロンプト設定）。
技術Python · FastAPI · Docker · browser_use · noVNC · Gemini / OpenAI / Anthropic
ChatCore-AI
AIチャット＆プロンプト共有 — 現在も運用中
2025年2月 – 継続中個人開発
FastAPIとNext.jsを用いたAIチャットアプリ。メール認証、Groq/Gemini API連携に加え、ユーザー間でプロンプトを共有・検索できる機能を搭載。nginx配下でBlue-Greenデプロイを組んで運用している。
技術Python (FastAPI) · Next.js · PostgreSQL · Redis · Docker · Groq / Gemini API
Symphony Agent Conductor
自律型エージェント・オーケストレーション基盤
2025年10月 – 2026年4月個人開発
LangGraphを用いた中央オーケストレーターを構築し、ブラウザ操作やIoT制御を行う専門エージェントを協調動作させることで、デジタル作業と物理デバイス制御のシームレスな連携を実現。
技術Python · Flask · LangGraph · browser-use · IoT (Jetson / Raspberry Pi) · OpenAI / Gemini
その他のプロジェクト
-
チャット指示でデバイスを制御し、ダッシュボードやカメラ撮影を備えたIoT管理基盤。Jetson / Raspberry Pi / Pico Wに対応し、NVIDIA Jetson Orin Nano上でローカルLLMを動かして低遅延・オフライン対応のエッジ処理を実現。
-
チャットで日々のルーティンやタスクを管理し、タイムライン表示にも対応するスケジュール管理アプリ。OpenAI / Gemini / Anthropicのモデルを切り替えて利用できる。
-
生活領域の多分野知識をRAGで統合し、MCP対応・会話分析機能を備えた生活支援AI。
-
Gemini 3がゲームマスターとなり、密室殺人事件を毎回動的に生成するインタラクティブなミステリーゲーム。Nano Bananaを活用し、Gemini 3 東京ハッカソン 2026にて開発。
-
QRによる即時共有、合言葉付きのグループ共有、リアルタイム共有ノートを備えたセルフホスト型のファイル／メモ共有ツール。
期間はGitHubリポジトリの作成から最終更新までを基準にしているため、実際に着手した時期より遅く出ている場合があります。
開発で苦労した点
Case Notes実際に時間を溶かした7つの問題を、試したことと最終的に効いた手当てまで書いています。最初の判断そのものが間違っていたケースも含めています。学びが大きかったのはむしろそちらです。
01 LLMエージェントの日付計算ハルシネーション対策
苦労したこと
LLMエージェントが日付・曜日の計算を頻繁に誤った。「来週の金曜日にランチを入れて」と指示しても別の日に登録されるケースが多発。LLMは確率的なテキスト生成をベースにしており、「今日から何日後が来週の金曜か」という決定論的な計算でさえ文脈のゆれで答えがぶれる。プロンプト改善だけでは限界があった。
解決策
LLMに日付を計算させるのをやめ、役割を分離した。LLMの担当はユーザーの意図を読み取ること（「来週の金曜」がどの曜日を指すかの判断）に限定し、実際の日付計算は常に正しい結果を返す専用の決定論的な関数群に委ねた。これによりどのモデルでも日付処理が安定した。9モデル×10タスクのベンチマークも実施し、中堅モデルが複数のフロンティアモデルを上回ることを確認。モデル性能だけに頼らず、設計で信頼性を担保するという判断の正しさを実証できた。
02 本番環境特有のnginxプロキシ問題 — SSEバッファリングとWebSocketアップグレード
苦労したこと
異なるプロジェクトで同じ根本パターンの障害を2度経験した。ローカル開発ではnginxを経由しないため発覚せず、本番デプロイ後に初めて顕在化するという共通構造。ChatCore-AIではLLMのトークン逐次配信（SSE）が本番でバッファリングされ全文一括表示になり、FS-QRではWebSocketによるテキストのリアルタイム同期が本番で接続できなかった。
解決策
SSEは、nginxのデフォルトのレスポンスバッファリングが原因で、proxy_buffering offとX-Accel-Buffering: noの追加で解決。WebSocketは、nginxがデフォルトでHTTP/1.0を使用しハンドシェイクに必要なUpgradeヘッダーが転送されていないことが原因で、locationブロックにproxy_http_version 1.1・Upgrade／Connectionヘッダー・タイムアウト延長を追加して解決。複数インスタンス間のブロードキャストにはRedis Pub/Subを採用した。異なるプロトコル・異なるプロジェクトで同じクラスのバグを踏んだことで、ストリーミングや持続接続は本番相当のnginx構成で検証するという習慣が身についた。
03 OSSの内部状態汚染 — 前タスクの残留状態が次タスクに干渉
苦労したこと
効率化のためブラウザセッションをタスク間で使い回す設計にしたところ、前のタスク終了後にライブラリ内部へ残留した状態が次タスクの実行に干渉した。セッションを完全に終了させると次のタスクが実行できず、そのままにすれば状態が積み上がってクラッシュする。どちらの選択肢も機能しなかった。
解決策
ライブラリには内部状態をリセットする公開APIが存在しなかったため、ソースコードを直接読んで内部構造を把握し、タスク終了ごとに状態をリセットするクリーンアップ処理を独自実装した。さらにバージョンによって内部構造が異なるため、バージョンに応じて動作を切り替えるフォールバックも追加し、どのバージョンでも動作するようにした。公開APIの限界に当たったときはドキュメントではなくソースコードを読むという判断の重要性を学んだ。
04 LLMが自分の生成内容に矛盾する問題 — 二重LLM検証ループ
苦労したこと
Geminiにミステリーの事件データ（登場人物・アリバイ・証拠・タイムライン）を生成させ、そのデータをもとにゲームマスターとして回答させたところ、自分で生成した事件と矛盾する回答が多発した。犯人のアリバイを正確に話してしまう、嘘つき設定のキャラクターが正直に答えてしまうなど、ゲームとして成立しないケースが続出した。
解決策
7時間という制約の中で、二段構えの回答パイプラインを実装した。①まず通常どおり回答を生成し、②別のLLM呼び出しで回答と事件データを照合して矛盾を検出・修正してからプレイヤーに届ける。あわせて、事件データ生成時に構造的に不正な出力を検出してやり直す仕組みも追加した。LLMは同じコンテキスト内で自分が生成した情報を参照して自己検閲することが苦手であり、生成と検証を別の呼び出しに分離する設計が有効だという知見を得た。
05 シェルスクリプトの実行権限によるGitHub Actions CDの失敗
苦労したこと
GitHub Actionsによる自動デプロイが、デプロイスクリプト（./deploy.sh）の呼び出しステップで毎回失敗した。ローカルで bash deploy.sh と実行すると問題なく動作するため原因が掴めず、CIランナー上の「Permission denied」を見てもすぐにはピンとこなかった。ファイルは存在し、内容も正しかった。
解決策
原因は、実行権限（+x）がgitのインデックスに記録されていなかったこと。ローカルで chmod +x を実行してもgitはファイル内容だけを追跡しており、git update-index --chmod=+x deploy.sh で明示的にステージングしなければ反映されない。この変更をコミットすることでランナーにも実行権限が継承され、デプロイが成功した。ローカルの bash script.sh 実行は実行権限を要求しないため問題が顕在化せず、ファイルシステムのパーミッションとgitが追跡するパーミッションの違いがCIでの直接実行で初めて露見するという構造を学んだ。
06 顔認証ログインの精度不足 — ボトルネックはモデル容量ではなく学習データ
苦労したこと
ResNetとTensorFlowで顔認証ログインシステムを構築したが、認証精度が想定より上がらなかった。最初の打ち手としてモデルの表現力が足りないと考え、隠れ層を追加して容量を増やした。しかし精度はほとんど改善せず、限られた学習データに対して容量だけを増やすのは過学習を招きかねない逆効果の方向だった。
解決策
精度の頭打ちはモデルの表現力ではなく学習データの量と多様性の不足側にあると切り分けた。顔画像を回転させたり明るさを調整したりしてデータ拡張を行い、撮影角度や照明条件のばらつきを学習データに与えたところ、モデルがそれらの変動に頑健になり精度が向上した。「精度が低い＝モデルを大きくする」と短絡せず、ボトルネックがモデル側（表現力）かデータ側（量・多様性）かをまず切り分けることの重要性を学んだ。
07 Blue-Greenデプロイの切り替えタイミング不備による瞬間的な500エラー
苦労したこと
ゼロダウンタイム更新を目指し、GitHub Actionsとnginxを組み合わせたBlue-Greenデプロイを導入したが、切り替え時に一瞬だけ500エラーが発生した。調査の結果、Dockerコンテナ自体は起動しているものの、内部のアプリケーションプロセスが完全に立ち上がる前にnginxの向き先を新しい（Green）環境へ切り替えていたことが判明した。
解決策
デプロイスクリプトにアプリケーションレベルのヘルスチェック待ちを追加した。単にコンテナの起動を待つのではなく、アプリケーションの /health エンドポイントをポーリングし、実際に200 OKが返ることを確認してからnginxの向き先を切り替えてリロードする流れに改善。完全に準備が整ったインスタンスにのみトラフィックが流れるようになり、エラーは解消した。「コンテナの起動」と「アプリケーションの準備完了」は別物であり、CI/CDには実用的なヘルスチェックが要るという教訓を得た。
学歴
Education慶應義塾大学大学院 政策・メディア研究科
政策・メディア研究科 サイバーインフォマティクス専攻 修士課程
University of North Alabama
交換留学プログラム修了
- 栄誉 成績優秀者（Dean’s List）選出（2023年秋期、GPA 3.75 / 4.0）。
- 1位 / 30人 人工知能（AI）授業の最終プロジェクトでクラス1位。OpenCV・TensorFlowで顔認証ログインシステムを開発。
- 主要履修科目：人工知能（AI）、HCI/UX入門、デザイン I & II、コンピュータ応用。
活動歴
Activities松尾研究室 関連プログラム・コンペティション
LLM講座・コンペティション・専門講座
- 上位4% LLM講座 最終プロジェクト＆コンペティション：LoRA SFTおよびDPOを用いたモデルを開発し、1,800人中70位に入賞。開発モデル：Llama-3.1-8B-Instruct-Freedom_v3
- LLMコンペ2025：チーム内で学習データ作成を担当し、数学的推論向けの高難度合成データセットを構築・公開。 → difficult_math_deepseek_llama
- 専門講座受講：AI経営講座（PwC共同開催）、LLM講座、GCI（データサイエンス基礎）、深層学習、深層生成モデル。
NCSP’26（国際会議）
2026 RISP International Workshop on Nonlinear Circuits, Communications and Systems
- 英語口頭発表 AIマルチエージェント・オーケストレーションシステムに関する研究成果を英語の口頭セッションで発表。
- 5種の専門エージェント（RAG・Web操作・IoT・Scheduler・Orchestrator）を統合した自律型システムを開発。
- → 発表資料（NCSP-Presentation-EN.pdf）
- → NCSP’26 公式プログラム（NCSP26_Sessions.pdf） / NCSP’26 公式サイト
Gemini 3 東京ハッカソン 2026
7時間の制限時間内に完成
- GeminiとNano Bananaを活用したミステリーゲームを、7時間の制限時間以内に完成させた。 → Gemini3-Hackathon-Mystery-Game
スキル
Skills- プログラミング言語
- PythonTypeScriptSQL
- Web / アプリケーション
- FastAPIReactNext.jsTailwind CSSPostgreSQLRedis
- AI / LLM エンジニアリング
- RAGMulti-Agent SystemsLangChainLangGraphbrowser-use
- インフラ
- DockerAWS (EC2, VPC, Systems Manager)LinuxNginxGitGitHub Actionspytest
- IoT / ハードウェア
- NVIDIA Jetson Orin NanoRaspberry Pi 4Pico W
- AIツール
- CodexClaude CodeNotebookLMAntigravityGeminiChatGPTClaude
AIツールの使い方
製品名を並べても中身が伝わらないので、どの工程で何に使っているかを書いておきます。設計判断とレビューは一貫して自分が持ちます。ツールが変えるのは進む速さであって、結果の責任の所在ではありません。
- リサーチ・学習 NotebookLM
- 論文・技術ドキュメント・講義資料を取り込み、要約や構造化されたノートを作る。未知の分野でも、実装に入る前に足場を作るために使う。
- 資料作成・プレゼン Claude
- スライド・ドキュメント・技術レポートを起案し、反復的に改善する。内容の出どころとしてではなく、構成と明瞭さを詰めるための書き手の相方として使う。
- コーディング・開発 Codex, Claude Code, Antigravity
- 新機能のスキャフォールディング、デバッグ、テスト作成、リファクタリング。エージェント型のツールはフルスタックの複数ファイルにまたがる変更に使う。ただし設計判断とレビューは自分が持つ。
- アイデア出し・問題解決 Gemini, ChatGPT, Claude
- アーキテクチャの意思決定やトレードオフの検討。ある方針に踏み切る前に、対話しながら妥当性を叩く用途で使う。
- 日本語
- ネイティブ
- 英語
- ビジネスレベル TOEIC 715 ／ 米国大学での1年間の留学 ／ 国際会議での英語口頭発表