サイオステクノロジーのインターンシップに参加した、東京電機大学の森田です。
今回のハッカソン型インターンでは、チーム開発の推進とアプリ実装を主導しました。
本記事では、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チューニングの実践力」を武器に、エンジニアとしてのキャリアを築いていきます。
