<p>株式会社Azitでエンジニアリングマネージャーをしている岩瀬です。<br>この記事をご覧いただきありがとうございます。現在、株式会社Azitで「プロダクトデリバリー責任者」というポジションを募集しています。<br>この記事は、たとえばこんな方に向けて書いています。</p><ul><li>エンジニアとして、顧客と直接向き合いながら課題を解決したい</li><li>PMとして、技術を活かしながら顧客の業務変革まで踏み込みたい</li><li>SIerやSaaSベンダーで働く中で、自分の仕事が価値を生んでいるか実感が持てない</li></ul><p>「技術かビジネスか」の二択ではなく、両方を活かしたい。そんな方に向けて、COO直下のこのポジションについて具体的な業務内容から魅力までお伝えします。</p>

<h2 id="h5d117ac32c">なぜこのポジションが必要なのか</h2><h3 id="h9df9f86b8d">SCM領域の現状</h3><p>私たちがForecastXを通じて向き合っているのは、エンタープライズ企業のSCM（サプライチェーンマネジメント）領域です。<br>意外に思われるかもしれませんが、日本を代表するような大企業でも、この領域の業務はExcelと属人的な運用に依存していることが少なくありません。それどころか、システム化・デジタル化以前の手作業が残っているケースすらあります。需要予測、在庫管理、発注計画といった基幹業務が、担当者個人の経験と勘に支えられているのです。<br>これは、私たちAzitが物流領域で顧客と向き合う中で、ずっと見てきた課題です。<br>現場の担当者に「なぜこの方法で運用しているのですか」と聞いても、明確な答えが返ってこないことがあります。「前任者から引き継いだやり方だから」「ずっとこれでやってきたから」。そういった答えが返ってくることも珍しくありません。<br>そして変化を難しくしているのは、「現状でまわっている」という事実です。大きな問題が起きていないからこそ、変える力学が働きにくい。誰も積極的に変えようとしない。この状態が、何年も続いているケースが多いのです。</p>

<h2 id="h41ea97d6df">従来のソリューションの限界</h2><p>では、この課題を解決するにはどうすればよいのでしょうか。</p><h3 id="h0ecaa17a5e">SIerに依頼する場合</h3><p>ゼロからシステムを開発すれば、顧客固有の課題に対応できます。しかし、費用対効果を考えると現実的ではありません。エンタープライズ企業のSCM領域をフルスクラッチで開発すると、数億円規模の開発費用がかかることも珍しくありません。「現状でまわっている」業務に対して、それだけの投資判断を下すのは難しいのです。<br></p><h3 id="h4cf6351e7f">一般的なSaaSを導入する場合</h3><p>SaaSは導入コストを抑えられますが、「導入して終わり」になりがちです。<br>エンタープライズ企業のSCM業務は、企業ごと、拠点ごと、商品カテゴリごとに異なります。固定化されたプロダクトをそのまま当てはめるだけでは、この多様性に対応できません。属人化した業務フローは、そのまま残り続けます。結局、表面的な対応では根本的な課題は解決しないのです。</p>

<h2 id="h234d29a3b8">ForecastXというプロダクト</h2><p>私たちAzitが提供するForecastXは、SaaSとSIの中間に位置するSCMプラットフォームです。需給予測などの汎用的なモジュールを持ちながら、個社の状況に合わせたカスタムモデルを搭載できる設計になっています。。<br>ただし、プロダクトを提供するだけでは価値は届きません。「顧客ごとに異なる業務フロー、基幹システム、組織構造に合わせて、プロダクトを「使える状態」にする必要があります。この「汎用的な機能」と「顧客固有の課題」の間を繋ぐことで、はじめて価値を届けることができます。</p>

<h2 id="h051a064bc4">だからこのポジションが必要</h2><h3 id="ha3efce42b3">求められる能力</h3><p>これを実現するには、顧客の基幹システムとForecastXを連携させるためのAPI設計やデータ変換、業務フローに合わせたシステム構築など、技術的な実装が発生します。そのため、エンジニアの技術・知識が不可欠です。同時に、顧客の懐に深く入り込み、属人化した業務の実態を理解することも必要です。<br>さらに、導入して終わりではありません。継続して運用を並走し、業務フローの改善まで伴走することが求められます。コスト削減効果を可視化し、実際に実現するまでが仕事です。<br></p><h3 id="h06a4138eed">なぜCOO直下なのか</h3><p>このポジションは、顧客の業務フローを変革し、億単位のコスト削減という財務インパクトを起こす役割です。顧客の経営層と直接やり取りしながら、導入から運用定着まで責任を持ちます。また、プロダクト・営業・データサイエンスなど社内の複数部門を横断した調整も必要です。事業運営に深く関わるポジションだからこそ、COO直下に置いています。<br>また、このポジションはプロダクトチームとは別に設けています。理由は2つあります。<br>1つ目は、役割の違いです。プロダクトチームの役割は、良いプロダクトを作ることです。一方、顧客のコスト削減を担う役割は、プロダクトという手段を使って目的を達成する仕事です。手段と目的の関係にあり、役割が異なります。<br>2つ目は、全体最適と個別最適の違いです。プロダクトチームは、多くの顧客に共通する価値を提供するプラットフォームを開発します。これは全体最適の仕事です。一方、このポジションは、個社固有の業務フローや基幹システムに合わせた開発・導入を行います。これは個別最適の仕事です。どちらも必要ですが、アプローチが異なるため、役割を分けています。<br></p><h3 id="h9a7683ce5f">他の職種との違い</h3><p>「エンジニアなのかコンサルなのか」「PM/PdMとは何が違うのか」という疑問があるかもしれません。<br>一般的なエンジニアは、プロダクト開発や機能実装が主な業務です。このポジションでは、それに加えて顧客の業務理解、導入支援、効果検証まで担います。技術力は必要ですが、それだけでは足りません。<br>PM/PdMは、プロダクトの企画・設計・開発管理が主な業務です。このポジションでは、プロダクトを顧客に届け、成果を実現するところまでが仕事です。プロダクトを作る側ではなく、プロダクトを使って顧客のコスト削減を実現する側です。<br>コンサルタントは、戦略立案や提言が主な業務です。このポジションでは、自ら手を動かして実装・実行まで担います。提言して終わりではなく、実際に結果を出すところまで責任を持ちます。</p>

<h2 id="h0b1e401176">このポジションの魅力</h2><p>ここまで、なぜこのポジションが必要かをお伝えしました。ここからは、働く方にとっての魅力をお伝えします。エンジニアやPMとして働く中で、こんな疑問や不安を持っていませんか？<br></p><h3 id="h7eabfe82a8">「自分の仕事は本当に価値を生んでいるのか」</h3><p>プロダクト開発や機能実装に携わっていても、それが実際にどれだけの価値を生んでいるのか、実感しにくいことがあります。ユーザーの声が届かない。売上への貢献が見えない。自分の仕事が本当に意味のあるものなのか、分からなくなる。<br>このポジションでは、自分の判断・設計が顧客の経営数字として返ってきます。在庫削減額、欠品率の改善、発注精度の向上。成果が数字で可視化されるため、「自分の仕事が価値を生んでいる」という実感を得られます。<br></p><h3 id="h5ba65046d4">「顧客の声が直接聞けない」</h3><p>大きな組織では、顧客との間に営業やカスタマーサクセスが入り、エンジニアやPM/PdMが一次情報を得る機会は限られます。伝言ゲームで届く要望。本当の課題が見えないまま進む開発。そんな経験はないでしょうか。<br>このポジションでは、顧客の現場に入り込み、要望をダイレクトに聞くことができます。しかも、聞いて終わりではありません。業務理解から技術設計・実装・運用定着まで、最初から最後まで一貫して責任を持てます。<br></p><h3 id="h5412e5870c">「導入を担当しているが、その先に関われない」</h3><p>SaaSの導入支援やカスタマーサクセスと聞くと、「結局は後処理係なのでは」「プロダクト本体の開発から外れた周辺業務では」と感じる方もいるかもしれません。<br>このポジションでは、顧客の成果を実現するために、何をすべきかを自ら判断し、推進します。責任と権限がセットで与えられ、事業視点での意思決定に関わります。単なるサポート役ではなく、成果に責任を持つ立場です。<br></p><h3 id="hdf4fdc73dd">「技術かビジネスか、どちらかを選ばないといけないのか」</h3><p>キャリアを積むにつれて、技術を極めるかビジネスサイドに移るか、選択を迫られることがあります。でも、本当は両方に関わり続けたい。エンジニアだけど顧客と話したい。ビジネスサイドだけど手を動かし続けたい。<br>このポジションでは、顧客の業務理解からシステム設計・実装・運用定着まで、技術とビジネスの両方に関わり続けることができます。どちらかを捨てる必要はありません。<br></p><h3 id="h7a3e4ab489">「専門性が中途半端にならないか」</h3><p>技術とビジネスの両方に関わると聞くと、「どちらも中途半端になるのでは」と不安に感じる方もいるかもしれません。<br>しかし、この掛け合わせ自体が専門性です。技術だけ、ビジネスだけの人材は多くいますが、両方を高いレベルで兼ね備えた人材は希少です。エンタープライズ顧客の経営課題に対して、技術で解決策を実装できる人材の市場価値は高い。このポジションでは、その経験を積むことができます。<br></p><h3 id="he81bf8094b">「最新のAIツールを使いたいが、会社の制約で使えない」</h3><p>生成AIを業務で活用したいのに、セキュリティやコストを理由に制限されている。そんな経験はないでしょうか。<br>Azitでは「AI駆動開発」を推進しています。Claude Code、GitHub Copilot、coderabbitなど、様々なAIツールを業務で活用しています。希望すれば好きなLLMやツールを会社経費で使用でき、新しいものを試すのに障壁はありません。AIを「試しに使う」レベルではなく、開発プロセスの中核に据えて実務経験を積めます。<br></p><h3 id="h256df80171">「自分の仕事が社会に貢献している実感が持てるか」</h3><p>日々の業務に追われる中で、自分の仕事が社会にどう貢献しているのか、実感しにくいことがあります。<br>私たちが向き合っているのは、日本の製造、商社、メーカーなどのエンタープライズ企業です。彼らのSCM業務を改善することは、最終的に私たちの生活にも繋がっています。スタートアップのスピード感を持ちながら、社会インフラに直結する仕事ができる。エンタープライズ特有の制約や難しさはありますが、だからこそ動かせたときのインパクトは大きい。<br></p><h3 id="h8502dcccb9">「このポジションからどんなキャリアが描けるのか」</h3><p>このポジションから将来どんなキャリアが描けるのか、気になる方もいると思います。<br>COO直下で経営視点の業務経験を積むことで、物流・SCM領域における希少な人材として成長できます。技術とビジネスの両方を理解し、エンタープライズ顧客の経営課題を解決できる人材は、将来的にCxOやCLO（Chief Logistics Officer）といったキャリアも視野に入ります。</p>

<h2 id="h10391a4a6b">応募を検討している方へ</h2><p>この記事を読んで少しでも興味を持っていただけたなら、嬉しく思います。<br>「社内にこもって開発するより、顧客と直接話したい」「マネジメント専任になるより、現場で手を動かし続けたい」「エンジニアだけど顧客と話したい」「ビジネスサイドだけど技術にも関わりたい」——そんな思いを持ちながら、今の環境ではそれが叶わないと感じている方。このポジションは、その志向を存分に発揮できる場所だと考えています。<br>一方で、「求められるスキルが幅広すぎて、自分には務まらないのでは」と感じた方もいるかもしれません。正直に申し上げると、今すべてのスキルが揃っている必要はありません。というより、すべてを兼ね備えた人材はいないと認識しています。私たちが求めているのは、新しい領域に対して能動的に学び、成長できる姿勢です。<br>顧客と直接向き合い、技術とビジネスの両方を活かしながら、自分の判断で動きたい。そんな方からのご応募をお待ちしています。</p>

<h2 id="ha214098e44">まとめ</h2><p>この記事では、COO直下のこのポジションについてお伝えしました。<br>エンタープライズ顧客のSCM領域に深く入り込み、ForecastXを通じてコスト削減を実現する。技術とビジネスの両方を活かしながら、顧客の経営に直接貢献できる仕事です。<br>世の中では、このような役割を「FDE（Forward Deployed Engineer）」と呼ぶ動きがあります。AI時代において、製品を導入しただけでは価値が生まれません。顧客の業務に深く統合し、「成果」を実現する人材が求められています。FDEは、顧客の業務とプロダクトの間に入り、証明された価値を"実装された成果"に変えるエンジニアです。<br>Azitのこのポジションも、同じ課題認識から生まれました。</p>

COO直下｜プロダクトデリバリー責任者

COO直下｜エンタープライズ顧客の意思決定・業務をAIで変える「プロダクトデリバリー責任者」とは

Iwase Takeshi

<h2 id="h8d027c8ed3">はじめに</h2><p>はじめまして、株式会社AzitのCTOの十亀です。 2025年は一年を通して、「生成AIと組織として、そして一人の開発者としてどう付きあうか」というテーマが、ずっと頭のどこかにありつづけた年でした。<br>本記事では、2025年をふりかえりながら、株式会社Azitとして生成AIとどのように向きあってきたのかを整理し、現時点での考えを共有します。</p>

<h2 id="hfe0be7637c">積極的に実験をする</h2><p>生成AIを取り巻くエコシステムは変化の周期が異例に短く、モデル性能やツールチェーンの最適構成が、数か月単位で刷新される環境です。 そのため、ひとつのプレイヤーに絞って利用したり、逆に「勝者が決まるまで待つ」というスタンスを取ってしまうと、実際にモデルをどう活用すべきかという知見を得ること自体が難しい領域であると感じました。<br>そこで弊社では、生成AIに関しては次のような方針で進めています。</p><ul><li>入力データの取り扱い範囲や外部送信の有無、ログの扱い等のセキュリティ基準を設ける</li><li>併せて、ツールの運営企業等の信頼性や情報管理ポリシー等の安全面で必要最低限のチェックをおこなう</li><li>一方で、ROIの事前の厳密な議論をしすぎない</li><li>会社として確保したバジェット内で、複数のツールを併用しながら試す</li></ul><p>この方針を取ることで、新しいモデルやツールがリリースされた際にも、予算内であればすばやく導入してトライできるようにしています。<br>また、利用頻度が下がったツールについても、「一度やめたからといって、また戻せないわけではない」<br>という前提で、いったん利用停止し、必要に応じて再検討する運用をおこなっています。 結果として、生成AIを特別視しすぎることなく、「小さく試し、合わなければ戻る」という実験のリズムを保ち続けることができました。</p>

<h2 id="h112b1ab03c">生成AIの成長と変わる関係性</h2><h3 id="h191827e441">投資対効果がまだ厳しかった年初</h3><p>年初の社内チャットをふりかえってみると、当時の生成AIとの距離感がよく表れています。 生成AIをつかってコーディングや実装にトライするものの、既存の前提を無視した修正が返ってきたり、発生したエラーにたいして適切な修正判断ができず、誤った修正対応を行き来するループに入ってしまったりする場面が少なくありませんでした。<br>人間側が状況を整理し、指示の粒度を調整しなければ、機能そのものが完成しない。 当時は、そのようなケースが多く、生成AIに実装をそのまま任せることの難しさを強く感じていました。<br>モデル側にも、コンテキスト制限や一般的なコーディング知識の不足といった制約があり、要件や方針をまとめて渡して実装を任せるよりも、CursorやCopilotといったエディタ補完を中心に進める方が、結果としてリターンが大きいと感じる時期でした。<br>一方で、単に補完ツールとして使うだけではなく、実験として、AIに渡す要件の抽象度を変えながら、</p><ul><li>どのくらいの粒度で指示を出すと、期待しているコードが出てくるのか</li><li>どの抽象度で破綻しやすいのか</li></ul><p>を日々探っていました。<br>今のモデルと比較すると、当時はプロンプトの文章としての精緻さが、出力の品質に及ぼす影響が現在と比べるとそれほど大きくありませんでした。 そのため、誤字脱字や走り書きに近い指示を投げても、一定のアウトプットが返ってくる、という感覚もありました。 ただし、その気楽さがそのまま「実装を任せられる」ことを意味するわけではなく、当時の実感は次の通りでした。</p><ul><li>モデル側はまだ「コーディングを完全に代替する」段階には来ていない</li></ul><p>そのため当時は、自分の使い方を Agentic Typing と呼び、意思決定をAIにほとんど委ねず、「文字列フィールド xxx を追加してください」といった、タイピングを省略する用途で使っていました。 実装のコントロールの主体は、ほぼエンジニア自身が握っている状態だったと思います。</p>

<h2 id="h0dff81abf8">モデルの進化とともに、AIに実施させる領域を段階的に広げる</h2><p>しかし、新しいモデルがリリースされるにつれて、この境目は徐々に変わっていきました。 こちらが担っていた領域の一部をAI側に寄せても、品質や速度が大きく崩れない。むしろ、その方が安定する。そう感じる場面が増えてきました。<br>2025年12月現在、私自身は Agentic Coding と呼ばれる手法を中心に開発をおこなっており、自分の手で直接コードを書いていることは、以前よりもかなり少なくなっています。<br>具体的には、</p><ul><li>AIに既存のコードベースの調査を依頼する</li><li>別のプレーンテキストエディタなどで設計方針や要件を整理する</li><li>整理した内容をプロンプトとしてAIに渡す</li><li>テストや型検査といったガードレールを通しながら実装を収束させる</li></ul><p>といった流れで、ほぼ満足のいくコードが得られるようになりました。<br>（このブログを書いている現在も、エディタ上で機能の実装がAIによって進んでいるのを見まもっています。）<br>また、巷で Vibe Coding と呼ばれるような、より多くの領域をAIに委ねる手法についても、用途を限定して取り入れています。 たとえば「アイデアの発散」という場面では、実現したいUIの要件を伝えたうえで、複数のパターンを同時に実装させ、短時間で比較検討するといった使い方をしています。</p>

<h2 id="hd820843a27">生成AIが開発の中心になっても変わらないもの</h2><p>このように、AIに実施させる領域を段階的に広げていきながらも、人間がコーディングの中心だった頃から変わらない、むしろいっそう重要になったことがあります。<br>それは、</p><ul><li>暗黙の前提や隠れた依存がすくないコードであること</li><li>一部分だけを切りとって読んでも、挙動や意図が把握しやすい疎結合かつ明瞭なコードであること</li><li>静的解析や静的型検査、自動テストなどによって、自動的に検証できる領域を継続的に増やしていくこと</li></ul><p>といった点です。<br>これらは、人間が複数人で開発をおこなうチーム開発においても、新しいメンバーを迎えいれたり、久しぶりにコードを読む場面でも一貫して重要でした。<br>さらに、生成AIによるコード生成が開発の中心になっていく場合には、これらの重要性は増していきます。 統計的に予測を繰りかえすモデルの性質上、コードベース内の書き方のブレがすくなく、変更の影響範囲を予測しやすい構造であることが求められます。<br>仮に予測が誤ったとしても、自動的に誤りが検知されるようなガードレール（型検査・静的解析・テスト・CI）を整備しておくことで、生成AI自身がフィードバックループをまわし、適切な実装に収束しやすくなります。<br>初期のコーディングエージェントは、こういった「人間が詰みあげてきた、数学や工学、ソフトウェア資産に裏打ちされたツール」を十分に活用できず、車輪の再発明のようにAIがゼロから考える挙動が目立っていました。 一方で、近年のコーディングに特化したエージェントは、周辺環境にあるツールを前提として取り込み、その環境に適応する能力を持つようになってきています。<br>もともと私たちのチームには、テストカバレッジを高く保つ文化や、疎結合なアーキテクチャを意識する文化があります。 Railsにおいても RuboCop や RBS を積極的に活用し、それらのチェックが落ちるPRはマージしない、といった運用を続けてきました。<br>コーディングの中心が生成AIへと移っていくとしても、こうした文化は引き続き大切にしていきたいと考えています。</p>

<h2 id="hdabc9f83e7">生成AIと学び、生成AIと作る</h2><p>生成AIによって、コーディングという作業そのものは、今後さらに自動化が進んでいくと思います。 その結果、人間が直接コードを書く機会は、これまで以上に減っていくかもしれません。<br>一方で、その変化が進んだとしても、「自分が何を理解していて、何を理解していないのか」という境界を曖昧なままにすることは、適切ではないと感じています。 生成AIが書いたコードをそのまま受け入れるだけでは、実装の是非を判断したり、問題が起きたときに適切にガイドしたりすることができません。<br>ここで重要なのは、「すべてを自分で書くこと」ではなく、「どのような理解を持ったうえで任せているのか」を把握していることだと思います。 生成AIに実装を任せること自体は問題ではありませんが、その結果として出てきたコードについて、</p><ul><li>なぜこの実装になっているのか</li><li>どの前提に依存しているのか</li><li>どの選択肢を捨て、何を選んでいるのか</li></ul><p>を説明できない状態は、健全とは言えません。<br>私自身は、判断において「何を選んだのか」も重要ですが、それと同等、あるいはそれ以上に、「なぜ他の選択肢を選ばなかったのか」を説明できることが重要だと考えています。 そのためには、「他にはどのような選択肢があり得たのか」というストックを、常に自分自身の中に蓄えておく必要があります。<br>私自身は、生成AIを前提とした開発においても、「理解そのものを手放さない」ことが重要だと感じています。 ただし、それは従来と同じ学び方をそのまま続ける、という意味ではありません。<br>むしろ、生成AIを前提とすることで、理解するためのアプローチ自体を加速させることができると感じています。<br>たとえば、NotebookLMのようなツールを使うことで、論文や仕様書といった一次情報を、要点を保ったまま素早く把握できるようになりました。 全文を精読する前に構造を掴んだり、特定の前提や主張だけを抜き出して確認したりと、「読む」ことにかかる認知コストを大きく下げられています。<br>また、PLaMo翻訳のような翻訳技術によって、英語で書かれた最新の書籍や論文、技術記事を、ほとんどストレスなく読めるようになった点も大きいです。 言語の壁が下がったことで、「後で時間を取って読む」のではなく、「必要になった瞬間に読む」という選択を取りやすくなりました。<br>事実、私自身も、時系列予測やヒューリスティックな経路最適化アルゴリズムに関するサーベイや論文の読解、あるいは邦訳前の書籍や最新の技術記事をいち早く読むといった場面で、これらのツールを活用してきました。 実装と調査を行き来しながら、前提や選択肢を整理したうえでコードに戻る、という往復を、ほとんどストレスなく行えるようになったと感じています。<br>このように、生成AIと一緒に作りながら、同時に学ぶというサイクルを回せるかどうかが、これからの開発において重要になっていくと考えています。 最終的な判断や責任は人間が持ち続ける。その前提を保ったまま、生成AIを理解の補助としても活用していく。<br>生成AIによって「書く」ことのコストは下がっていきますが、「理解し、判断し、レビューする」ことの価値が下がるわけではありません。 むしろ、生成AIを前提とした開発では、その部分の重要性は、これまで以上に高まっていくように思います。</p>

<h2 id="ha214098e44">まとめ</h2><p>2025年は、生成AIを「便利な補助ツール」として扱う段階から、「開発プロセスの中心に置き、前提条件を整えた上で任せる」段階へと、距離感が大きく変わった一年でした。 モデルやツールの更新サイクルは速く、正解が固定されない領域だからこそ、私たちはROIを机上で固めすぎず、一定の基準を設けたうえで小さく試し、合わなければやめ、必要であれば戻る、という実験のリズムを重視してきました。<br>一方で、AIに任せられる領域が広がるほど、コードベース側の前提が問われます。暗黙の依存が少なく、局所的に読んでも意図と挙動が追える構造、そして静的解析・型検査・自動テストといった「機械で検証できる領域」を増やしていくこと。 これは人間中心の開発でも重要でしたが、AI中心の開発では、実装を安全に収束させるためのガードレールとして、より決定的な意味を持つようになりました。<br>来年も、生成AIそのものの進化は続きます。 だからこそ私たちは、特定のツールや手法に過度に依存するのではなく、「どんな環境でも品質を担保できる開発の型」と「変化に追従する運用」をセットで磨き続けます。 生成AIに過度に依存せず、ソフトウェア工学の積み上げの上に置かれた強力な道具として、安全に、そして着実にチームの生産性と品質に接続していく。2026年は、その精度をもう一段上げる一年にしたいと考えています。</p>

AIデータサイエンティスト

生成AIとの距離感が変わった一年 ─ CTOとして、任せる範囲を考え続けた記録

Sogame Masato

<p><span style="color:#000000">「Love from Azit」では、様々な角度からAzitについてご紹介しているメディアです。今回は、Monoful Venture PartnersのVP of Fund Managementである銚子周一郎さんをゲストにお迎えしました。</span><br><span style="color:#000000">一度は見送りとなった投資が、どのようにして実現に至ったのか。そして、DeliveryXからForecastXへの事業変遷の裏側にある学び、物流・サプライチェーン領域におけるスタートアップの「勝ち筋」について、Azit代表の吉兼がインタビュアーとなりお話を伺っています。</span></p>

<h2 id="h5c4d85c8fd"><span style="color:#000000">PROFILE</span></h2><p><strong style="color:#000000">銚子 周一郎氏 / Monoful Venture Partners / Senior Investment Manager</strong><br><span style="color:#000000">東京大学文学部卒業。新卒で入社したリクルートでは、B2B向けの営業・新規事業開発部門の事業開発・CVCに従事。CVC部門では、日本及び欧米のVC投資業務に従事し、B2B SaaS、Fintech、シェアリングなどの領域で投資。その後、YCPジャパン（現 YCP Solidiance）でディレクターとして成長戦略策定やPMI支援、飲食関連子会社の代表取締役を歴任。現在はMonoful Venture Partnersにて、物流・不動産分野や関連技術を持つスタートアップへの投資およびファンド運営を担当。</span></p>

<h2 id="he694725fd9"><span style="color:#000000">丁寧なフィードバックが繋いだ、Azitへの再投資</span></h2><p><strong style="color:#000000">―― 本日はよろしくお願いいたします。はじめてモノフルさんにご相談させていただいたのは随分前になりますね。当時、物流・SCM業界ということもありご相談させていただいたのがきっかけでした。実はそのときはご出資が叶わなかったのですが、お見送りの理由にもすごく納得感があって。厳しいご意見もすっと入ってくるような内容でした。当時林口さん（Monoful Venture Partners / Head of Investments）にご紹介いただいたのが銚子さんでしたね。</strong><br><span style="color:#000000">そうでしたね。弊社の林口も、投資する/しないということに対してフェアですし、事業理解を深めた上で、お断りする際もきちんとフィードバックするんです。私もそれを学んでいるので、お断りする際は丁寧に「なぜ今のタイミングで自分たちからの投資が難しいと思うか」を、説明させていただくようにしています。</span><br><br><strong style="color:#000000">―― その後改めて相談させていただき、ご投資いただくことになりましたが、当時のAzitの印象はいかがでしたか？</strong><br><span style="color:#000000">2回目の投資検討のタイミングで、1回目に宿題になっていた課題に真正面からぶつかって、新しい事業を持ってきたことに、私自身揺れ動くものがありました。これならトライさせていただきたいと思ったんですよね。また、最初にお話させていただいた頃から、吉兼さんを良い起業家さんだと思っていましたし。</span><br><span style="color:#000000">当時我々は割とミドル/レイターの投資が多かったので、Azitはアーリーでしたが、個人的にもっとアーリーに投資したいという思いもありました。なので実は、Azitはアーリーへの投資の第一号案件だったんですよね。そして、やっぱり、大きな絵を描いているところとタッグを組みたいという思いもありました。</span></p>

<p><strong style="color:#000000">―― ありがとうございます。現在はForecastXに注力していますが、CREWやDeliveryXをやることで得た反省も多くあります。例えば、配送の無駄を削っても出てくる成果は100→95のようなものですが、在庫の無駄を削ると一気に70まで無駄が排除できるようなイメージなんですよね。それこそ財務インパクトで言うと桁が一桁変わるくらい大きなインパクトを残せると感じました。その分予算もつきやすく、話がサクサク進むというのも実感しています。配送は複雑な課題である一方、ビジネスインパクトがやや薄く、どうしても企業の中でのプライオリティが上がりにくいところがあったので「予算があるところでBtoBは戦わないと推進力が下がるんだな」というのは学びとして強くありましたね。</strong><br><span style="color:#000000">その通りですね。物流やサプライチェーンって、現場のオペレーションが止められないじゃないですか。止めることはできないからどう段階的にやっていくんだって考えると、やっぱもっと上から、まさに上段から変革して過剰在庫を減らした方がよりコストインパクトがあるという発想に至る。これまでの物流事業に向き合ってきた総括としての今のテーマ設定が、これからのストーリーになる気がしています。</span><br><span style="color:#000000">ゼロから「サプライチェーンDX・AXのスタートアップです」と話すよりも、経営陣が現場や経営の課題を深く見てきた結果「下から登っていったら、金と課題が詰まっていたのはここでした」という方が、聞いている側、投資家としても顧客へのラポールもすごく効く気がしていて。</span><br><br><strong style="color:#000000">ーー そうですね。実際に今お客様の声を聞いていても、需要予測から始まって、在庫管理して、最後物流の管理までサプライチェーン全体を最適化したいというご要望をいただきます。やっぱり物流分野で様々な企業様を支援してきた上で、上からやらなきゃいけないと思っているんです。という話は、すごく熱量高く聞いてくださるんですよね。</strong><br><span style="color:#000000">それこそ「実はそこ（物流の部分）じゃないんですよ。御社の課題は」って言い切れてしまうと、多分4周分ぐらいショートカットする感じがしますよね。そして、日本のサプライチェーンの中で、変革への投資余力があり、意思決定権も兼ね備えた、エンタープライズの荷主企業様に着目されるのは、すごくセンスがいいとDeliveryXのときから思っていました。そこはクライアントを見立てるところはずれてないと思っています。</span></p>

<h2 id="h621cbc0276"><span style="color:#000000">SaaSでもSIでもない、「SaaS × SI」ハイブリッドモデルの面白さ</span></h2><p><strong style="color:#000000">―― 今もDeliveryXの運営は続けていて、エンタープライズの荷主企業の物流・SCMを変革するという大枠のテーマは変わっていませんが、今年より注力することに決めたのはForecastXです。銚子さんの目線でご覧になって、山の登り方みたいなところは全然変わってるじゃないですか。その変化をどう見ていますか。</strong><br><span style="color:#000000">先程申し上げた通り、可能性やポテンシャル、事業規模という観点でいうと、今のForecastX側のほうが大きいことは理解していました。ただ、当初の私の解像度では、「その領域にはSIerがいるのでは？」「ERPやCRM、在庫管理、WMSなど、業務システムが分断していて手が出せないのでは？」など、市場があると言っても“まるっとSIerの世界”だと思っていたんです。</span><br><span style="color:#000000">しかし、吉兼さんたちの話を聞く中で「ForecastXが切り取れる市場」が具体化されてきて、非常に面白い領域だと感じるようになりました。</span><br><br><strong style="color:#000000">ーー SIerが担っているのは、基本的に“データの管理”なんですよね。基幹システムも含め、受注データや在庫データといった情報を管理する役割を果たしています。ただ、サプライチェーンに本当に必要なのは「管理」ではなく「最適化」であり、そのためのAI、厳密にはアルゴリズムです。ところが、そういったAIはこれまで十分に適用されてきませんでした。</strong><br><strong style="color:#000000">つまり、基幹システムとの連携は必要なので、SIerが提供している基幹システムやWMSがなくなるわけではないし、そこは僕らが置き換える領域ではありません。必要なのは、「データを受け取り、どの在庫数にすべきか、どの販売量が適切か、物流をどう組むべきか」といった最適化だけを担うレイヤーなんです。そこでようやく、自分たちは“ワンレイヤー上に乗るアプリケーション”を作っているのだと明確になってきました。</strong><br><strong style="color:#000000">これまでスタートアップがこうした領域に挑むと、SaaSモデルでは個社カスタマイズが難しく、登りにくい山だったと思います。ただ、僕らはSaaS的な要素とSI的な柔軟さをハイブリッドにすることで、最適化のロジック部分に加え、アラートやダッシュボード、レポートなどは個社ごとにカスタマイズ可能にしつつ、予測データや在庫データの管理方法は共通インフラのまま提供できる。SaaSとSIを掛け合わせることで初めて成立したモデルだと感じています。</strong><br><strong style="color:#000000">さらに、AIの進化がこの領域にとてもフィットしていると感じています。以前ならSIのように大きな組織を作らなければできなかった個別開発が、今では「1社に1人貼り付けば、十分に高速で作り込める」世界になってきました。データの整形ひとつとっても、昔はPythonでスクリプトを書くのに長く時間がかかっていたものが、今はAIと少し対話するだけでデータが綺麗に整うようになっている。</strong><br><strong style="color:#000000">そうした意味でも、この領域は“時代感”や“AIの流れ”と非常に合っている、と強く感じています。</strong><br><span style="color:#000000">そうですね。そこは私も非常に期待しているポイントです。御社のビジネス、というより“スタイル”が面白いと感じているのは、単なるSaaSでもなく、SIでもなく、その中間にあるハイブリッドなモデルを追求しているところなんですよね。</span><br><span style="color:#000000">SaaSのスケーラビリティと、SIの柔軟さを掛け合わせることで、プロジェクト単価をしっかり取りにいける。もし、そのモデルの中から誰にでもわかりやすく伝わるような象徴的な成功事例としてカチッとはまれば、世間からの認知も含めて一気に美しい形になると思っています。</span><br><span style="color:#000000">そして、そこまで行けば、あとは“どう高速に顧客に価値を届けるか”という生産性のフェーズ、組織拡大のフェーズに移っていくはずです。</span><br><span style="color:#000000">AIを活用しながら、プロジェクトマネジメントができるコンサルタント、ある種エンジニアリング感覚も備えた、最近よく話題になるFDEのような人材が揃っていけば、そこからは組織全体の速度が一気に上がる。そんな未来が、見えてきていますよね。</span></p>

<h3 id="he194a9b879"><span style="color:#000000">「現場を変えないテクノロジー」と、若手が成長する環境</span></h3><p><strong style="color:#000000">―― 改めてこの物流のこの市場、先程SIerさんの話もありましたが、スタートアップが挑む価値ってどういうところにあると思いますか。また、投資家としてスタートアップには何を期待したいでしょうか？</strong><br><span style="color:#000000">先程もでましたが、物流やサプライチェーンは「止められない」業界です。だからこそ、既存のオペレーションを止めずに導入できるイノベーションが求められています。現場の人たちは「変えたいけど、止められない」という矛盾を抱えているんです。</span><br><span style="color:#000000">その中で、スタートアップに期待するのは、オペレーションの変革前提ではなくて、「今の仕組みを維持したまま進化できる」という体験を提供することだと思っています。現状のワークフローに寄り添いながら、外からのアイデアでとんでもないイノベーションを起こす──そんな黒船の登場を期待しています。</span><br><strong style="color:#000000">―― なるほど。今僕たちがやっていることは、端的に言うと「エクセルファイルの管理のリプレイス」なので、インプットとアウトプットのフォーマットが一緒だったら、現場の方々のワークフローは変わらずに作れるんですよね。</strong><br><span style="color:#000000">確かに。仰るような既存のオペレーションを一切変えずに、業務効率を劇的に改善できる、みたいな魔法を、現場は探しているんですよね。</span><br><span style="color:#000000">Azitって、今まさに現場から何が求められているか、そのアンテナの感度が高い経営陣がいるというところは大きいと思っています。</span><br><strong style="color:#000000">―― 僕たち自身は、事業ドメインは正直なんでも楽しいと思っています。（笑）</strong></p>

<p><span style="color:#000000">それがいいですよね。そういう感覚はすごい。特にその若手でテクノロジーもビジネスも興味ありますっていう人は、すごい相性いいなと思って。</span><br><span style="color:#000000">理系で新卒コンサルの道を選んだけど、標準端末しか使えなくて、「もっといろんなツールを自由に使えたら、課題解決のスピードも提供価値も全然違うはず」って思っている皆さんは、みんなAzitに来ればいいと思っています。</span><br><br><strong style="color:#000000">―― 大手クライアントの顧客の成果に繋げないといけないというのもありますし、かつ社内チームのプロダクトにも繋げなきゃいけないっていうミッションもある。それを楽しめる人だったら成長できるばではないかと思います。</strong><br><span style="color:#000000">確かにAzitのお客様は、日本社会の生活基盤と直結しているような大手企業が多くて、プロダクトの理解と顧客対応との両方が求められますね。若手が身につけるべきビジネススキルを得るには、非常に良い環境だと思いますよね。</span><br><br><span style="color:#000000">聞き手：吉兼周優　編集：坂井華子</span></p>

<h3 id="hda492ffe51"><span style="color:#434343">採用情報</span></h3><p><span style="color:#000000">Azitでは、各職種で採用を行っております。詳細は、以下のページをご覧ください。</span><br><a style="color:#000000" href="https://herp.careers/v1/azitinc" target="_blank" rel="noopener noreferrer">https://herp.careers/v1/azitinc</a></p>

【投資家が語る】なぜAzitに投資を決めたのか？ Monoful Venture Partners 銚子周一郎さんと紐解く、事業変遷と今後の可能性

Love from Azit 編集部

<h2 id="h8d027c8ed3">はじめに</h2><p>株式会社Azitでエンジニアリングマネージャをしている岩瀬です。<br>私たちは物流・SCM領域に特化したAIソリューションを提供しています。SCM領域のDXを進める中で気づいたのは、どれだけシステム化を進めても、現場には「電話」という最後の壁が残っているということでした。倉庫や配車の現場では車両の誘導や日程調整を電話で回していることが多く、営業部門も架電に相当なリソースを割いています。<br>そこで私たちは、音声AIを使った電話業務の自動化に挑戦することにしました。2024年12月から2025年3月にかけて、MVP開発として「AIがどの程度電話業務の穴を埋められるのか」「人と同じレベルの会話体験をどこまで作れるのか」を検証しました。<br>今回は、そのMVP開発で経験した試行錯誤と学びについて振り返ってみたいと思います。音声AIを使った開発に興味のある方、AIの可能性と限界を知りたい方の参考になれば幸いです。<br>※本稿は半年前に実施したMVP開発の振り返りです。当時遭遇した課題の一部は、現在の技術アップデートで改善されている可能性があります。</p>

<h2 id="h3af4d147a9">プロジェクト概要</h2><h3 id="hc6921f9b0d">目的と目標</h3><p>このMVP開発の主な目的は以下の3点でした。</p><ul><li>AI電話プロダクトが商品として販売可能かの仮説検証</li><li>顧客が導入後をイメージできるデモを提示できる状態にすること</li><li>インフラの固定・従量費用を具体的に把握すること</li></ul><p>ローカル環境で技術検証をするだけではなく、Twilio + Azure OpenAI Realtime APIを使ってサーバ上で動作する「製品に近い構成」を目指しました。</p><h3 id="h42a02e9f7f">シナリオ選定</h3><p>今回は2つのシナリオを開発しました。<br><strong>車両誘導（受電）</strong> ドライバーから電話を受けて、車番とドライバー名から予定情報を照合し、次の目的地や明日の予定、その住所や積載物などをAIがドライバーに伝達するシナリオです。日々の電話件数が多く、AIによる一次対応のニーズが顕在化していました。<br><strong>営業架電</strong> 見込み顧客に対して、サービスの紹介と打ち合わせの日程調整を行うシナリオです。オペレーターのリソースが限られており、効率化のインパクトが大きい領域でした。<br>受電と架電それぞれで課題や効果がどう違うかを比較することも狙いの一つでした。</p><h3 id="h7c6f298096">役割分担</h3><p>私（岩瀬）が進捗管理、基本設計、シナリオ設計、プロンプト作成を担当し、CTOの十亀さんが詳細設計と開発（インフラ構築・コーディング）を担当しました。</p>

<h2 id="hdf8a4d8b2f">システム構成</h2><h3 id="h1921e50ba5">全体構成</h3>

<p>システムは大きく分けて、電話を受け持つTwilio側と、音声処理を行うAzure側で構成されています。<br><strong>処理の流れ：</strong></p><ol><li>Twilioが電話を受信し、WebSocket経由でAzure上のコンテナに接続</li><li>コンテナがAzure OpenAI Realtime APIに接続し、音声の送受信を行う</li><li>必要に応じてAzure AI Searchを使ってRAG（検索拡張生成）を実行</li><li>プロンプトやRAG用データはNotionで管理し、バッチ処理でストレージに同期</li></ol><p>この構成は、Microsoftの公式サンプル（<a href="https://github.com/Azure-Samples/aisearch-openai-rag-audio" target="_blank" rel="noopener noreferrer">aisearch-openai-rag-audio</a>）をベースに構築しました。</p><h3 id="h572489ee0b">各サービスの役割</h3><p><strong>Twilio</strong> 電話の受発信を担当します。着信したらWebhookでAzure上のコンテナに接続し、音声データのストリーミングを行います。<br><strong>Azure OpenAI Realtime API</strong> 音声の入力と出力をリアルタイムで処理する、今回のシステムの中核です。従来のText-to-Speech/Speech-to-Textを組み合わせる方式と異なり、音声を直接入力して音声を直接出力できます。これにより低遅延の会話が可能になります。<br><strong>Azure AI Search</strong> RAGに使用します。プロンプトやFAQなどの情報をインデックス化し、会話の文脈に応じて必要な情報を検索・提供します。<br><strong>Notion</strong> プロンプトやRAG用データの管理に使用しました。</p><h3 id="h476540adb5">構成検討の経緯</h3><p>当初はDifyを使ってRAGを管理する構成を検討しました。しかし、Difyでリアルタイムの会話を扱おうとするとWebSocket接続に制約が多く、Twilioとの音声接続も難しいことがわかり断念しました。<br>Twilio単体でもテキスト読み上げは可能ですが、会話の途中で割り込めるようなリアルタイム性が欲しかったため、Azure OpenAI Realtime APIを選定しました。<br>また、プロンプトやRAGデータの管理にNotionを選んだのは、非エンジニアでもシナリオを編集できるようにする狙いがありました。ただし後述するように、途中でMarkdownファイルへの外部化に変更することになります。<br>なお、Realtime APIはリージョンに制限があり、当時はNorth Central USでのみ動作することを確認しています。</p>

<h2 id="hb844cbcf40">開発の流れと試行錯誤</h2>

<h3 id="h7ae5aaa5bd">Phase1：調査・準備（12月〜1月）</h3><p>最初の2ヶ月は、技術調査とMVP開発に向けた準備計画に費やしました。<br>主な作業内容は以下の通りです。</p><ul><li>既存の音声AIスタックの調査</li><li>システム構成の検討と技術選定</li><li>Azure環境の構築（ACR Tasks権限エラーやリージョン問題への対処）</li><li>Twilio-Azure OpenAI Realtime API連携の検証</li><li>Notion連携の検討</li><li>費用試算（月額5万円規模）</li></ul><p>特にAzure環境の構築では、無料枠ではACR Tasksが使えないことや、リージョンによって動作しないことがあり、試行錯誤が必要でした。十亀さんがこれらの技術的な課題を一つずつクリアし、ローカル環境でTwilioとRealtime APIを接続して会話できることを確認しました。</p><h3 id="h9f36804bd1">Phase2：MVP開発と問題の発生（2月）</h3><p>2月からMVP開発を本格的に開始しました。車両誘導と営業架電の両シナリオを並行して開発し、実際に電話をかけて動作を確認しました。<br>当初は「<strong>バージイン</strong>（AIが話している途中でも人が割り込める設定）」で開発を進めました。より自然な会話に近づけたいという狙いでしたが、ここで深刻な問題に直面します。<br><strong>相槌で会話が破綻する問題</strong><br>最も深刻だったのが、人が「はい」「えぇ」「うんうん」といった相槌を打つと、AIの発話が中断してしまう問題でした。<br>これはRealtime APIのVAD（Voice Activity Detection：音声検出）機能が、人の発話を検知するとAIの発話を即座に中断する仕様によるものです。意味のある発言と相槌を区別できないため、相槌も「人が話し始めた」と認識してしまいます。<br>さらに問題だったのは、AIの発話が中断されると、プロンプトで指定した会話の流れを無視して次に進んでしまうことでした。例えば、営業シナリオでサービスの詳細を説明している最中に相槌を打たれると、説明を飛ばして次の質問に進んでしまいます。会話が完全に破綻してしまうのです。<br><strong>その他の問題</strong><br>相槌問題以外にも、多くの問題が発生しました。</p><ul><li>人の発言に関係なく音声が途切れる</li><li>漢字や数字の読み方が間違っている</li><li>名前や電話番号の照合がうまくいかない</li><li>会話のフローを飛ばしてしまう</li></ul><p>これらの問題の詳細は後述しますが、2月の時点では「このままでは実用化は難しい」という状況でした。</p><h3 id="h936bc357ab">Phase3：大きな転換点（3月）</h3><p>3月上旬、プロジェクトにおける大きな転換点がありました。2つの抜本的な改善を実施したのです。<br><strong>1. ターン制への切り替え</strong><br>バージインから、「<strong>ターン制</strong>（AIと人が交互に話す設定）」への切り替えを決断しました。<br>ターン制では、AIの発話が完了してから人の発話を受け付けます。Twilioのmark機能を使って、AIの発話完了を管理する実装を行いました。実際には<code>outgoing_call_turn</code>として別のコードベースで管理しています。<br>この変更により、相槌でAIの発話が中断される問題は解消されました。バージインによる自然な会話は失われましたが、会話のフローが飛ぶ問題はほぼ解消し、会話の安定性が大幅に向上しました。<br>意外だったのは、人は思った以上に相手の発話終了を待てるということです。「待たされ感」を心配していましたが、実際にはそれほど大きな違和感はありませんでした。<br><strong>2. プロンプトの構造化</strong><br>もう一つの大きな改善が、プロンプトの外部化と構造化です。<br>当初はNotionのページをそのまま読み込んでいましたが、Notionから取得したテキストは構造が崩れており、AIが会話のフローを正しく認識できていない可能性がありました。単に相槌で会話が飛ぶだけでなく、そもそもフローの理解が曖昧だったのです。<br>そこで、プロンプトをNotionからMarkdownファイルへ外部化し、見出しや箇条書きを使って明確に構造化して記述しました。これにより、AIが会話のフローを正しく認識できるようになり、意図通りに動作する確率が高まりました。<br>また、一時期プロンプトをコードにベタ書きしていたこともあり、Notionを更新しても反映されないという事故も経験しました。外部化することで、デプロイなしでシナリオを更新できるようになり、開発効率も向上しました。<br>ターン制への切り替えは「相槌による中断」を防ぐための対策、プロンプトの構造化は「フローの正しい認識」を実現するための対策です。似ているようで目的は異なりますが、両方を実施することで相乗効果が生まれました。<br><strong>成功体験</strong><br>この2つの改善を実施した後、初めて電話をかけたときのことは今でも覚えています。<br>間が空かず、発話が被らず、想定したフローに沿って会話が進む。目を瞑れば人っぽい、という段階にまでたどり着けたのです。この瞬間は、プロジェクトを通じて最も手応えを感じた瞬間でした。<br>そして何より、当初の目標であった「実際にAIと会話ができるデモを顧客に提示できる状態」を実現できたことが大きな成功でした。完璧ではないものの、電話をかけてAIと会話し、シナリオに沿ったやり取りができる。この実動するデモを提示できたこと自体が、プロジェクトの大きな成果でした。</p><h3 id="h2f49281eba">Phase4：プロダクト機能の拡充（4月）</h3><p>Phase3で想定通りの会話が実現できるようになった後、次のステップとしてプロダクトを顧客に提案するための機能追加に取り組みました。自社の営業が顧客に説明しやすく、かつ実際の業務で使えるイメージを持ってもらえるような機能を実装していきました。<br>この時期に実装した機能は以下の通りです：<br><strong>プロンプトチェイニング</strong><br>フロー遵守をさらに確実にするため、Function Callingを活用した「プロンプトチェイニング」を試しました。これは、最初に会話全体のフローをすべて渡すのではなく、関数を呼び出すとその結果として次のステップの指示が返ってくる仕組みです。<br>例えば、「ユーザーが興味を示したと判断したら<code>interest_matching_service</code>関数を呼び出してください。関数の結果に次の指示が含まれています」という形で、段階的にプロンプトを切り替えます。<br>劇的な変化があったわけではありませんが、フロー遵守の確実性が増したと感じました。<br><strong>会話の記録と要約</strong><br>電話業務では、誰とどんな話をしたかを記録することが重要です。そこで以下の機能を実装しました：</p><ul><li>会話の文字起こしをデータベースに記録</li><li>AIが会話内容を要約し、スプレッドシートに議事録として出力</li><li>通話終了後にSMSで定型メッセージを送信</li></ul><p>特に要約機能は、後から会話内容を振り返る際に有用な機能として、デモでも好評でした。<br><strong>日程調整の自動化</strong><br>実際の電話営業を想定し、「打ち合わせの日程調整」を自動化する機能を実装しました。Googleカレンダーと連携させることで、実務での活用シーンを具体的にイメージしてもらえるようにしました。<br>AIがカレンダーから空き時間を取得し、「4月21日の9時から10時まで、10時30分から12時まで...」といった候補を読み上げます。ここで工夫したのは、日程を形態素解析ツールでカタカナの読み仮名に変換したことです。「シガツニジュウイチニチノクジカラジュウジマデ」のように変換することで、読み間違いを防ぎました。<br>相手が希望する日程が決まれば、そのままカレンダーに予定を登録します。日程調整が完了する前に通話が切れた場合は、SMSを送らないように制御も加えました。<br><strong>架電リストとの連携</strong><br>電話営業の業務フローを再現するため、架電リストを読み取って自動で電話をかけ、通話後にチェックマークや議事録を追加する機能も実装しました。<br>これらの機能は、すべて実験的な実装でしたが、「AI電話を実際の業務フローにどう組み込むか」を考える上で重要な試行錯誤でした。</p>

<h2 id="hf4e866d110">発生した問題の全体像</h2>

<p>MVP開発を通じて発生した問題を整理すると、以下の4つのカテゴリに分類できます。開発時には個別に対処していましたが、振り返ってみると問題の性質ごとに分類できることがわかりました。</p><h3 id="h42684798dc">音声出力の問題</h3><p><strong>相槌で音声が切れる</strong><br>前述の通り、最も深刻だった問題です。AIが話している最中に人が「はい」「うんうん」「へー」といった相槌を打つと、AIの発話が途中で停止し、会話のフローが飛んでしまいます。<br><strong>音声が途切れる</strong><br>人の発言に関係なく、AIの音声が途中で途切れることもありました。文章の区切りで途切れる場合と、単語の途中で切れる場合があり、原因の特定が困難でした。<br>通信の遅延や処理の影響が考えられますが、明確な原因は特定できませんでした。<br><strong>速度・発音・イントネーションの揺らぎ</strong><br>同じ会話でも、AIの話す速度やイントネーションが一定ではありませんでした。録音して聴き比べると、極端に早くなったり遅くなったり、一瞬別人のように聞こえることもありました。<br>また、発音が不明瞭になり「噛んだ」ように聞こえることもありました。例えば「お打ち合わせ」が「おとうあわせ」に聞こえるといった具合です。<br>これは音声処理の性能、特に当時のRealtime APIが英語に最適化されており、日本語への最適化が十分でなかったことが原因と考えられます。</p><h3 id="h03802b23ff">読み上げの問題</h3><p><strong>漢字の読み方が違う</strong><br>地名の読み方を間違えることが頻繁にありました。</p><ul><li>「目黒区三田」の「三田」を「みた」ではなく「さんだ」と読む</li><li>「葛飾区新宿」の「新宿」を「にいじゅく」ではなく「しんじゅく」と読む</li></ul><p>メジャーな読み方が優先されてしまい、マイナーな読み方は使われにくいようです。<br><strong>日付・番地の読み方が違う</strong><br>日付や住所の番地の読み方も問題でした。</p><ul><li>「1日」を「ついたち」ではなく「いちにち」</li><li>「20日」を「はつか」ではなく「にじゅうにち」</li><li>「1/3」を日付ではなく分数として読む</li></ul><p>特殊な読み方がある日付は壊滅的に間違えることがありました。<br><strong>数字の読み方がおかしい</strong><br>電話番号のような桁数の多い数字では、読み違える率が非常に高くなりました。</p><ul><li>数字を飛ばす：「09011001234」→「ぜろきゅういちいちぜろいちにさん」</li><li>違う数字を読む：「09011001234」→「ぜろきゅういちにさんぜろさんよんごろく」</li><li>桁を混同する：「09011001234」→「ぜろきゅうぜろせんひゃくじゅうにさんじゅうよん」</li></ul><p>電話番号として認識している場合と、単純な数字の並びとして認識している場合が混在し、読み方が安定しませんでした。</p><h3 id="h10f55468a5">理解・判断の問題</h3><p><strong>照合の精度が低い</strong><br>名前や電話番号などを人に言わせて、AIがデータと照合する処理がうまくいきませんでした。例えば、人が伝えた4桁の車番とデータにある車番の照合が正しく行われないことがありました。<br>AIは単語や文節に区切って前後関係で処理しているため、完全一致や前方一致といった厳密な照合が難しいようです。数字の照合は特に壊滅的でした。<br><strong>判断が人と異なる</strong><br>「興味がある場合」と「興味がない場合」で分岐させる際に、人間とは異なる判断をすることがありました。<br>例えば、「あります」と回答した場合は「興味がない」の分岐に入り、「はい、あります」と回答した場合は「興味がある」の分岐に入るといった具合です。<br>日本語的な曖昧な言い回しをうまく処理できないことが原因と考えられます。</p><h3 id="h672d18a33a">フロー制御の問題</h3><p><strong>フローを遵守できない</strong><br>会話のフローを指示しても、フローを飛ばしたり指示通りに分岐できなかったりすることがありました。</p><ul><li>概要を説明した後に詳細を説明すると指示しているのに、詳細の説明を飛ばす</li><li>質疑応答をしてから日程の調整をすると指示しているのに、質疑応答を飛ばす</li></ul><p>プロンプトでフローチャートを表現しにくいこと、AIが前後関係で処理しているためフロー全体を把握できていないことが原因と考えられます。<br><strong>指示を無視する</strong><br>プロンプトの指示を守らなかったり、部分的に抜かしたりすることもありました。</p><ul><li>「早口で話してください」と指示しても早口にならない</li><li>「復唱してください」と指示しても復唱しない</li><li>禁止事項を守らない</li></ul><p>実行時の優先度や遵守度合いに揺らぎがあり、指示が厳格に守られるわけではないようです。</p>

<h2 id="h1aae3b05ce">デモでの反応</h2>

<p>社内外に向けてデモを実施し、様々な反応を得ることができました。</p><h3 id="h23a63fe584">ポジティブな反応</h3><p>音声で「人みたいに話す」ことへの驚きは予想以上に大きいものでした。AIがリアルタイムで応答し、自然に会話できることに対して、純粋な驚きと興味を示していただけました。<br>ターン制に切り替えた後は、シナリオ逸脱が減ったことに対して前向きな評価も得られました。</p><h3 id="he98b33d46e">課題の指摘</h3><p>一方で、デモ中に問題が露呈することもありました。無音や読み間違い、相槌対応の問題が出ると、評価は一気に下がりました。<br>特に印象的だったのは、顧客の期待値の高さです。顧客は「人の代替」を前提として見ており、100%に近い精度を期待されていました。少しでも問題が出ると「まだまだ」という評価になります。<br>料金に対する強い反応は少なかったものの、割高感の指摘はありました。関心は常に「人の代替ができるか」に集中しており、補助的な活用という提案は受け入れられにくい印象でした。</p>

<h2 id="hc86d473fe5">音声AI開発で学んだ教訓</h2><p>このプロジェクトを通じて得た重要な教訓をまとめます。</p><h3 id="hb2090bc3aa">1. AIは想像以上に人のように話せるが、人の期待値はさらに高い</h3><p>最も驚いたのは、AIが想像以上に人のように話せるということでした。技術の進歩は予想を上回っており、適切に設定すれば「目を瞑れば人っぽい」レベルの会話が実現できます。定型的な会話や、感情を考慮しなくてよい会話は、すでにAIで実施可能なレベルにあります。<br>しかし、人の期待値は現状の技術を上回っています。<br>顧客はAIに「人と同等かそれ以上」を求めており、100%に近い精度を期待しています。「人の手が回らないところを補助させる」という提案は、なかなか受け入れられません。<br>さらに興味深かったのは、人間には寛容なのにAIには厳しいという反応です。言い間違いやイントネーション、発音の揺らぎなど、人間でも起こることに対して、AIがやると目くじらを立てられることが多くありました。電話で人が対応していたら大抵無視するレベルの小さなミスでも、AIだと「システムなのに」と厳しく指摘されるのです。<br>現時点では人の期待値が過剰であり、AIの適切な活用領域を理解してもらうことが大きな課題だと感じました。</p><h3 id="hae6ae37cc1">2. AIのランダム性との付き合い方が難しい</h3><p>AIの発言にはランダム性があり、それがよく働くこともあれば、悪く働くこともあります。<br>よく働く例としては、会話が自然になることが挙げられます。毎回全く同じ言い回しではなく、微妙に表現を変えることで、人間らしさが生まれます。<br>一方で、悪く働く例としては、指示を守らなかったり、重要な情報を言い間違えたりすることがあります。特に電話番号や住所といった厳密性が求められる情報で問題が出ると、実用上大きな支障になります。<br>だからといって厳密性を求めてランダム性を完全に排除すると、既存の音声案内のようになってしまいます。「ただいま、サービスの、ご案内を、いたします」といった機械的な話し方では、AIを使う意味が薄れてしまいます。<br>自然さと正確さのバランスをどう取るかが非常に難しいと感じました。用途によって最適なバランスは異なるため、一律の答えはなく、個別に調整していく必要があります。</p><h3 id="h7227eb87b1">3. システム設計とプロンプト設計の両面からのアプローチが必要</h3><p>音声AI開発では、技術的な実装だけでなく、プロンプト設計が非常に重要であることを実感しました。<br>ターン制への切り替えはシステム側の対応、プロンプトの構造化はプロンプト側の対応です。どちらか一方だけでは不十分で、両面からアプローチすることで相乗効果が生まれました。<br>また、問題が発生したときに、それがAIの限界なのか、プロダクトの実装で解決できることなのかの切り分けに多くの時間を費やしました。この切り分けができないと、適切な対策を打てません。<br>音声AI開発は、システムエンジニアリングとプロンプトエンジニアリングの両方のスキルが求められる領域だと感じました。</p>

<h2 id="h9be0c3393d">おわりに</h2><p>今回のMVP開発は、音声AIの可能性と課題を実感できる貴重な経験となりました。<br>技術的には、相槌や復唱を「無視してよい発言」として聞き分ける精度向上や、地名・日付・数字の読み上げ品質の改善が今後の課題です。OpenAI Realtime APIはturn-takingの改善や速度調整パラメータなど、日々新しい機能が追加されており、これらの課題も近い将来解決される可能性があります。<br>私たちAzitでは、ForecastX（需給予測）やDeliveryX（配車最適化）といったSCM領域のAIソリューションを提供しており、今回の音声AIもその一環として検証を行いました。AIを活用した新しいソリューションの開発に興味のある方、一緒に挑戦したい方は、ぜひお気軽にお声がけください。<br>最後まで読んでいただき、ありがとうございました。</p>

OpenAI Realtime APIでAI電話を作った話

<h2 id="h8d027c8ed3"><span style="color:#1f2328">はじめに</span></h2><p><span style="color:#1f2328">「午前中の打ち合わせで出たフィードバック、午後にはデモに反映できますか？」</span><br><span style="color:#1f2328">従来の開発プロセスでは、この問いに「はい」と答えられる人は少ないでしょう。しかし、AI駆動開発ツール「Claude Code」を活用することで、コーディング経験がほぼない私でも、これを日常的に実現できるようになりました。</span><br><span style="color:#1f2328">本記事では、株式会社Azitの新規プロダクト「ForecastX」のデモ開発において、PdMである私がClaude Codeを用いてどのようにAI駆動開発を実践したか、その具体的なプロセスと成果をお伝えします。</span></p>

<h2 id="hee50120e89"><span style="color:#1f2328">筆者について</span></h2><p><span style="color:#1f2328">株式会社AzitでPdM（プロダクトマネージャー）を務める佐々木寅彦です。物流・サプライチェーン領域のAIソリューション開発に携わっています。</span><br><span style="color:#1f2328">重要な前提として、私にはコーディング経験がほぼありません。HTMLを少し触った程度で、本格的なプログラミングは未経験。そんな私が、React + TypeScriptで構築された本格的なデモアプリケーションを開発・運用することになりました。</span></p>

<h2 id="h1836afb25c"><span style="color:#1f2328">プロジェクトの背景</span></h2><h3 id="heb12d85afa"><span style="color:#1f2328">ForecastXとは</span></h3><p><span style="color:#1f2328">ForecastXは、Azitが開発中の需給予測プラットフォームです。従来の需要予測システムは導入費用が数千万円規模、開発期間も半年以上かかることが一般的でした。ForecastXは、低価格かつ最短1ヶ月での導入を目指しています。</span><br></p><h3 id="h8c3e5e8516"><span style="color:#1f2328">なぜPdMがデモ開発を行うことになったのか</span></h3><p><span style="color:#1f2328">新規プロダクトの立ち上げ期において、最も重要なのは「顧客が本当に求めているものは何か」を素早く検証することです。しかし、従来のプロセスでは：</span></p><ol><li>PdMが顧客ヒアリングで要件を整理</li><li>エンジニアに開発を依頼</li><li>数週間〜数ヶ月後にデモが完成</li><li>顧客に見せてフィードバックを得る</li><li>再度エンジニアに修正を依頼...</li></ol><p><span style="color:#1f2328">このサイクルでは、1回のフィードバックループに数週間かかることも珍しくありません。</span><br><span style="color:#1f2328">そこで私は、PdM自身がデモ開発を行うというアプローチを取ることにしました。顧客と直接対話している人間が、その場で得た知見をすぐにプロダクトに反映できれば、圧倒的なスピードで検証サイクルを回せるはずだと考えたのです。</span></p>

<h2 id="ha777a68998"><span style="color:#000000">プロジェクト概要 - 何を作ったのか</span></h2><p><span style="color:#000000">今回開発したのは、ForecastXを中心としたサプライチェーン管理の統合プラットフォームのデモです。</span><br></p><ul><li>規模:<ul><li>6つのプロダクト: 需要予測、在庫計画、販売計画、補充計画、生産計画、発注計画</li><li>各プロダクト6つの機能: 計画、分析、アラート、ダッシュボード、カスタムレポート、データ管理/連携</li><li>合計36ページ: 6プロダクト × 6機能</li></ul></li><li>技術スタック:<ul><li>React + TypeScript（Claude Codeからの提案）</li><li>サンプルデータもすべてClaude Codeが生成</li></ul></li><li>開発期間: 約2週間（その後は必要に応じて日次単位で修正開発）</li></ul>

<h2 id="hf70eef0964"><span style="color:#1f2328">Claude Codeとの出会い</span></h2><h3 id="hc82c6a834c"><span style="color:#1f2328">最初の一歩</span></h3><p><span style="color:#1f2328">Claude Codeを使い始めた当初、正直なところ半信半疑でした。「本当にコードが書けない人間でも使えるのか？」という疑問がありました。</span><br><span style="color:#1f2328">しかし、実際に使ってみると、その印象は大きく変わりました。Claude Codeは単にコードを生成するだけでなく、私の意図を理解し、適切な実装方針を提案してくれるのです。</span><br><span style="color:#1f2328">例えば、「需要予測のグラフを表示したい」と伝えると、単にコードを出力するのではなく：</span></p><ul><li>どのようなライブラリを使うべきか</li><li>データ構造はどうあるべきか</li><li>ユーザビリティの観点から何を考慮すべきか</li></ul><p><span style="color:#1f2328">といった点まで含めて提案してくれました。</span><br></p><h3 id="h57d0c452d0"><span style="color:#1f2328">初期構築から運用フェーズへ</span></h3><p><span style="color:#1f2328">最初のデモ構築には約2週間かかりました。React + TypeScriptの環境構築から、基本的なUIコンポーネントの作成、データの可視化機能の実装まで、一通りの機能を揃えるのにそれなりの時間が必要でした。</span><br><span style="color:#1f2328">しかし、本当の価値はここからでした。</span></p>

<h2 id="hd77629fd89"><span style="color:#1f2328">「当日アップデート」という新常識</span></h2><h3 id="h3f6da54f00"><span style="color:#1f2328">最短数時間での修正サイクル</span></h3><p><span style="color:#1f2328">初期構築後、私の開発スタイルは劇的に変化しました。顧客やステークホルダーからフィードバックをもらったら、最短数時間、遅くても1営業日以内で修正を完了できるようになったのです。</span><br><span style="color:#1f2328">具体的なシーンを挙げると：</span><br><span style="color:#1f2328">午前の打ち合わせ→午後には反映 顧客との午前中のミーティングで「この画面にアラート機能があると便利」という声をいただく。午後にはClaude Codeでアラート機能を実装することができる。</span><br><span style="color:#1f2328">Slackでのフィードバック→当日対応 社内からSlackで「グラフの色をもう少し見やすくしてほしい」という依頼が来る。その日のうちにUIを調整し、「確認お願いします」と返信できる。</span><br><span style="color:#1f2328">このスピード感は、周囲からも驚かれることが多いです。「え、もう対応できたの？」「こんな短時間でPDCAを回して高速でデモ改修できるんですね」といった反応をいただきます。</span><br></p><h3 id="h4f2f1d7f93"><span style="color:#1f2328">エンプラ顧客への提案を変えた「個社別カスタマイズ」</span></h3><p><span style="color:#1f2328">AI駆動開発の真価が発揮されたのは、エンタープライズ顧客への提案時でした。</span><br><span style="color:#1f2328">物流・製造業の顧客は、それぞれ固有のニーズを持っています。ある企業は製品の保管期限管理を重視し、別の企業は特殊なアラート機能を求める。汎用的なデモでは、こうした個別のニーズに応えることができません。</span><br><span style="color:#1f2328">従来であれば、個社ごとにデモをカスタマイズするには相応の開発工数が必要でした。しかし、Claude Codeを活用することで、私はFDE（Forward Deployed Engineer）的な動きを1人で実現できるようになりました。</span><br><span style="color:#1f2328">FDE的な動きとは：</span></p><ol><li>顧客の現場に入り込み、ヒアリングを行う</li><li>要件を整理し、プロダクトへの落とし込みを検討する</li><li>短期間でデモをカスタマイズし、すぐに顧客に見せる</li></ol><p><span style="color:#1f2328">特に3番目のステップが重要です。従来は「汎用的なデモをお見せして、導入時にカスタマイズします」という説明になりがちでしたが、私は各社向けにFDE業務を行った後の、最適化されたプロダクトをデモとして共有できるようになりました。</span><br><span style="color:#1f2328">具体的なカスタマイズ例：</span></p><ul><li>実際の拠点名・商品名の反映: 顧客が実際に使用している拠点名（例：「東京倉庫」「大阪倉庫」）や商品名をデモに反映。汎用的な「拠点A」「商品1」ではなく、顧客にとってリアリティのある画面を見せられる</li><li>業務フローに合わせた機能追加: 保管期限の表示、特定条件でのアラート発火など、各社の業務フローに合わせた機能を追加</li><li>UIの調整: 顧客が重視する情報を目立つ位置に配置するなど、見せ方の最適化</li></ul><p><span style="color:#1f2328">これにより、提案時に「これは御社向けにカスタマイズしたデモです」と言えるようになりました。汎用デモを見せて「実際の導入時にはカスタマイズします」と説明するのとは、顧客へのインパクトがまったく違います。</span></p>

<h2 id="hf70a276f7d"><span style="color:#1f2328">開発プロセスの実際</span></h2><h3 id="ha7e770a1c4"><span style="color:#1f2328">日常的なワークフロー</span></h3><p><span style="color:#1f2328">現在の私の開発ワークフローは以下のようになっています：</span></p><ol><li>要件の整理<ul><li>顧客フィードバック、社内からの要望を収集</li><li>優先度を判断し、対応する項目を決定</li></ul></li><li>Claude Codeへの指示<ul><li>実現したいことを自然言語で説明</li><li>必要に応じて画面のスクリーンショットや参考資料を共有</li></ul></li><li>コードの生成と適用<ul><li>Claude Codeが生成したコードを確認</li><li>意図通りの実装になっているかをプレビューで確認</li></ul></li><li>動作確認とフィードバック<ul><li>実際にデモを動かして確認</li><li>問題があればClaude Codeに修正を依頼</li></ul></li><li>デプロイ<ul><li>GitHubへのプッシュ</li><li>本番環境への反映</li></ul></li></ol><p><span style="color:#1f2328">このサイクルを1日に何度も回すことで、高速なイテレーションを実現しています。</span><br></p><h3 id="h1ff5ba6ccc"><span style="color:#1f2328">学んだこと：AI駆動開発のコツ</span></h3><p><span style="color:#1f2328">約2ヶ月間の開発を通じて、いくつかのコツを学びました：</span><br><span style="color:#1f2328">1. 具体的に伝える：「かっこいいダッシュボードを作って」ではなく、「売上推移を折れ線グラフで表示し、前年同期比を並べて表示したい」、などと具体的に伝える。</span><br><span style="color:#1f2328">2. 段階的に進める：一度に大きな変更を求めるのではなく、小さな単位で確認しながら進める。</span><br><span style="color:#1f2328">3. エラーを恐れない：エラーが出ても、そのメッセージをClaude Codeに伝えれば、原因と解決策を提示してくれる。</span><br><span style="color:#1f2328">4. 既存コードの理解を深める：Claude Codeに「このファイルの構造を説明して」と聞くことで、自分が書いていないコードも理解できるようになる。</span><br><span style="color:#1f2328">5. 定期的なコードの見直し： Claude Codeでは、ほぼコードを見ずに開発することも可能な一方で、不要なコードの削除漏れなどが起きても気づきずらいため、定期的に「コードの見直し（リファクタリング）」を指示することで、開発を続けやすい環境を維持することができる。</span></p>

<h2 id="h41126f20c5"><span style="color:#1f2328">成果と効果</span></h2><h3 id="hda3cb31331"><span style="color:#1f2328">定量的な成果</span></h3><ul><li>初期デモ構築: 約2週間</li><li>機能追加・修正: 最短数時間〜1営業日</li><li>開発した画面数: 6プロダクト × 複数画面</li><li>エンジニア工数: ほぼゼロ（レビューのみ）</li></ul><h3 id="hef743a7640"><span style="color:#1f2328">定性的な効果</span></h3><p><span style="color:#1f2328">1. 顧客との対話の質が向上：「次回の打ち合わせまでに反映します」ではなく「明日には反映します」と言えることで、顧客との信頼関係が深まった。</span><br><span style="color:#1f2328">2. 仮説検証のスピードアップ：「この機能は本当に必要か？」という問いに対して、実際に作って見せることで素早く検証できるようになった。</span><br><span style="color:#1f2328">3. PdMとしての視野の拡大：技術的な制約や実装の難易度を肌で感じることで、より現実的な要件定義ができるようになった。</span><br><span style="color:#1f2328">4. エンジニアリソースの有効活用：デモレベルの開発はPdMが担当し、エンジニアは本番プロダクトの開発に集中できる体制を構築できた。</span></p>

<h2 id="h9be0c3393d"><span style="color:#1f2328">おわりに</span></h2><p><span style="color:#1f2328">「コーディング未経験のPdMがデモ開発を行う」というのは、少し前までは現実的ではありませんでした。しかし、Claude Codeのようなツールの登場により、技術とビジネスの境界は確実に薄くなっています。</span><br><span style="color:#1f2328">特に重要なのは、「2週間で作れる」ことではなく、「当日アップデートできる」ことです。この圧倒的なスピード感があるからこそ、顧客との対話を通じて本当に価値のあるプロダクトを作り上げることができます。</span><br><span style="color:#1f2328">もちろん、AI駆動開発は万能ではありません。複雑なビジネスロジックや、高度なパフォーマンス最適化が必要な場面では、専門のエンジニアの力が不可欠です。しかし、プロダクトの初期検証やデモ開発においては、PdMが自ら手を動かすことで得られる価値は計り知れません。</span><br><span style="color:#1f2328">この記事が、同じようにAI駆動開発に興味を持っている方、あるいは「技術がわからないから...」と躊躇している非エンジニアの方の参考になれば幸いです。</span></p>

<h2 id="hb953b41752"><span style="color:#1f2328">株式会社Azitについて</span></h2><p><span style="color:#1f2328">Azitは「日本のインフラを新しい時代へと紡ぐ」をミッションに、物流・サプライチェーン領域に特化したAIソリューションを提供しています。需給予測プラットフォーム「ForecastX」、AI配車プラットフォーム「DeliveryX」などを通じて、サプライチェーン全体の最適化を目指しています。</span></p>

BizDev｜ストラテジック・パートナー

コーディング未経験のPdMが、プロダクトデモの「当日アップデート」を実現した話

Torahiko Sasaki

<h2 id="h8d027c8ed3">はじめに</h2><p>株式会社Azitでエンジニアリングマネージャーをしている岩瀬です。<br>前回の記事「需給予測モデル開発で実践するAI駆動開発手法」では、バイブコーディングからAI駆動開発への移行と、体系的な開発テンプレートについて紹介しました。今回は、その開発フローを実際に回す中で遭遇した問題と、その解決策について紹介します。<br>AI駆動開発を実践していると、避けて通れない問題があります。それは<strong>コンテキストウィンドウの限界</strong>です。長時間のセッションで作業を続けていると、AIが過去の経緯を忘れ、同じミスを繰り返すようになります。<br>この記事では、Claude Code Hooksを活用して作業記録を自動保存する仕組みを構築した経験を共有します。なお、この機能自体もAI駆動開発で実装しました。コーディングは全てAIが担当し、人間はアイデア出しと指示に徹しています。</p>

<h2 id="h2f128147ec">遭遇した問題：コンテキストウィンドウの限界</h2><h3 id="hb6770a6f36">LLMの本質的な制約</h3><p>LLM（大規模言語モデル）は本質的に<strong>ステートレス</strong>です。つまり、前回の会話を記憶していません。会話を継続するには、毎回全ての情報をコンテキストウィンドウに含める必要があります。<br>しかし、このコンテキストウィンドウには上限があります。Claude Codeの場合、200Kトークン（約15万語相当）が上限です。長時間の開発作業では、ファイルの内容、コードの変更履歴、やり取りがどんどん蓄積され、この上限に達してしまいます。<br>上限に近づくと、Claude Codeは自動的に<strong>コンテキスト圧縮</strong>を実行します。過去の会話履歴を要約し、トークン数を削減するのですが、この過程で重要な情報が失われることがあります。</p><h3 id="hd59c266a8b">世間での問題認識</h3><p>この問題は私だけが経験しているものではありません。技術ブログやSNSなど、様々な場所で開発者から報告されています。</p><ul><li>圧縮後にClaude Codeの性能が低下し、どのファイルを見ていたか忘れて再読み込みが必要になる</li><li>セッション中に数回の圧縮を経ると、AIが逆に生産性を下げるようになる</li><li>30分前に与えた指示を完全に忘れ、設定を何度も聞いてくる</li><li>複雑なタスクの途中で圧縮が発生すると、作業の継続が困難になる</li></ul><h3 id="h5166b2595c">私が体験した問題</h3><p>私の場合、特に厄介だったのは<strong>先祖返り</strong>の問題です。<br>コードを修正した理由をAIが忘れてしまい、以前と同じバグを再び作り込んでしまうことがありました。「なぜこの実装にしたのか」という経緯が失われると、同じ試行錯誤を繰り返すことになります。<br>これはAI駆動開発において深刻な問題です。人間がプロジェクトマネジメントに徹し、AIが実装を担当する体制では、AIが過去の判断を忘れると、人間が全ての経緯を記憶・管理しなければならなくなります。それでは、AI駆動開発のメリットが大きく損なわれてしまいます。</p>

<h2 id="h59422e0872">解決策：Claude Code Hooksによる作業記録自動作成</h2><h3 id="h9d3e2a9f2a">Claude Code Hooksとは</h3><p>Claude Code Hooksは、特定のイベント発生時に任意のスクリプトを実行できる機能です。以下のようなイベントをトリガーにできます：</p>

<table border="1">
  <thead>
    <tr>
      <th>イベント</th>
      <th>発生タイミング</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td><code>PreCompact</code></td>
      <td>コンテキスト圧縮の直前</td>
    </tr>
    <tr>
      <td><code>PostCompact</code></td>
      <td>コンテキスト圧縮の直後</td>
    </tr>
    <tr>
      <td><code>SessionEnd</code></td>
      <td>セッション終了時</td>
    </tr>
    <tr>
      <td><code>PreToolUse</code></td>
      <td>ツール使用前</td>
    </tr>
    <tr>
      <td><code>PostToolUse</code></td>
      <td>ツール使用後</td>
    </tr>
  </tbody>
</table>

<p>この機能を活用し、<strong>コンテキスト圧縮の直前</strong>と<strong>セッション終了時</strong>に作業記録を自動生成する仕組みを構築しました。</p><h3 id="h3412c47ccc">実装アーキテクチャ</h3><p>最終的に採用したアーキテクチャは以下の通りです：</p>

<pre><code>[PreCompact/SessionEnd イベント]
    ↓
[suggest-claude-md-hook.sh]（フックスクリプト）
    ↓
[nohup claude --dangerously-skip-permissions --print "/summarize-worklog {transcript_path}" &amp;]
    ↓
[バックグラウンドで作業記録生成]
    ↓
[docs/worklog/worklog.md に自動追記]</code></pre>

<p>ポイントは以下の3点です：</p><ol><li><strong>スラッシュコマンド方式</strong>：フック内で直接APIを叩くのではなく、新しいClaude Codeセッションを起動してスラッシュコマンドを実行</li><li><strong>バックグラウンド実行</strong>：<code>nohup ... &amp;</code>でバックグラウンド実行し、フック処理を即座に完了させる</li><li><strong>権限スキップ</strong>：<code>-dangerously-skip-permissions</code>オプションで、バックグラウンド実行時の対話的権限確認をスキップ</li></ol>

<h3 id="h865e5ab9a5">詳細な実装手順<br>1. ディレクトリ構造</h3><pre><code>.claude/
├── commands/
│   └── summarize-worklog.md    # 作業記録生成スラッシュコマンド
├── hooks/
│   ├── hooks.json              # フック設定
│   ├── common.sh               # 共通ヘルパ関数
│   └── suggest-claude-md-hook.sh  # メインフックスクリプト
├── logs/                       # フック実行ログ
├── proposals/                  # 提案ファイル格納
└── transcripts/                # トランスクリプトバックアップ

</code></pre><h3 id="h7260a5e5d5">2. フック設定（hooks.json）</h3><p><code>.claude/hooks/hooks.json</code>を作成します：</p><pre><code>{
  "PreCompact": [
    ".claude/hooks/suggest-claude-md-hook.sh"
  ],
  "SessionEnd": [
    ".claude/hooks/suggest-claude-md-hook.sh"
  ]
}

</code></pre><h3 id="h30185ae99a">3. 共通ヘルパ関数（<a href="http://common.sh/" target="_blank" rel="noopener noreferrer">common.sh</a>）</h3><p><code>.claude/hooks/common.sh</code>を作成します：</p><pre><code>#!/bin/bash

# 公式仕様準拠: Claude Code Hooks共通機能
# 再帰発火の無限ループ防止
if [ "${SUGGEST_CLAUDE_MD_RUNNING:-}" = "1" ]; then
    echo "[hook] already running; skip" &gt;&amp;2
    exit 0
fi
export SUGGEST_CLAUDE_MD_RUNNING=1

# プロジェクトディレクトリの検出
PROJECT_DIR="${CLAUDE_PROJECT_DIR:-$(pwd)}"

# CLAUDE.mdファイルの存在でプロジェクトルートを検証
if [ ! -f "$PROJECT_DIR/CLAUDE.md" ]; then
    search_dir="$(pwd)"
    while [ "$search_dir" != "/" ] &amp;&amp; [ ! -f "$search_dir/CLAUDE.md" ]; do
        search_dir="$(dirname "$search_dir")"
    done
    if [ -f "$search_dir/CLAUDE.md" ]; then
        PROJECT_DIR="$search_dir"
    fi
fi

# ディレクトリ構造の確保
PROPOSALS_DIR="$PROJECT_DIR/.claude/proposals"
WORKLOG_BASE_DIR="$PROJECT_DIR/docs/worklog"
LOG_DIR="$PROJECT_DIR/.claude/logs"

mkdir -p "$PROPOSALS_DIR" "$WORKLOG_BASE_DIR" "$LOG_DIR"

# 作業記録ファイル
WORKLOG_FILE="$WORKLOG_BASE_DIR/worklog.md"

# ワークログファイルを初期化（存在しない場合のみ）
if [ ! -f "$WORKLOG_FILE" ]; then
    cat &gt; "$WORKLOG_FILE" &lt;&lt; EOF
# プロジェクト作業記録

**作成日**: $(date +%Y-%m-%d)

## 作業記録

EOF
fi

# 統一ログ機能
HOOK_LOG="$LOG_DIR/hook_execution_$(date +%Y%m%d).log"

log_info() {
    local msg="$1"
    local timestamp="$(date '+%Y-%m-%d %H:%M:%S')"
    echo "[CLAUDE-HOOK] $msg" &gt;&amp;2
    printf '{"timestamp":"%s","level":"INFO","message":"%s","pid":%d}\\\\n' \\\\
        "$timestamp" "$msg" "$$" &gt;&gt; "$HOOK_LOG"
}

log_error() {
    local msg="$1"
    local timestamp="$(date '+%Y-%m-%d %H:%M:%S')"
    echo "[CLAUDE-HOOK ERROR] $msg" &gt;&amp;2
    printf '{"timestamp":"%s","level":"ERROR","message":"%s","pid":%d}\\\\n' \\\\
        "$timestamp" "$msg" "$$" &gt;&gt; "$HOOK_LOG"
}

</code></pre><h3 id="h982a922c73">4. メインフックスクリプト（<a href="http://suggest-claude-md-hook.sh/" target="_blank" rel="noopener noreferrer">suggest-claude-md-hook.sh</a>）</h3><p><code>.claude/hooks/suggest-claude-md-hook.sh</code>を作成します（主要部分を抜粋）：</p><pre><code>#!/bin/bash

SCRIPT_DIR="$(cd "$(dirname "$0")" &amp;&amp; pwd)"
source "$SCRIPT_DIR/common.sh"

log_info "Hook started: $(basename "$0")"

# JSONペイロード処理
payload="$(cat)"
log_info "Hook payload received"

# Python でJSON解析
parse_official_payload() {
    local payload="$1"
    python3 -c "
import sys, json
payload = '''$1'''
try:
    data = json.loads(payload)
    print('TRANSCRIPT_PATH:' + data.get('transcript_path', ''))
    print('HOOK_EVENT_NAME:' + data.get('hook_event_name', 'unknown'))
    print('SESSION_ID:' + data.get('session_id', ''))
    print('CWD:' + data.get('cwd', ''))
    print('REASON:' + data.get('reason', ''))
except Exception as e:
    print('TRANSCRIPT_PATH:')
    print('HOOK_EVENT_NAME:unknown')
"
}

PARSE_RESULT="$(parse_official_payload "$payload")"
TRANSCRIPT_PATH="$(echo "$PARSE_RESULT" | grep '^TRANSCRIPT_PATH:' | cut -d: -f2-)"
HOOK_EVENT_NAME="$(echo "$PARSE_RESULT" | grep '^HOOK_EVENT_NAME:' | cut -d: -f2-)"
CWD="$(echo "$PARSE_RESULT" | grep '^CWD:' | cut -d: -f2-)"

# CWDを使用してプロジェクトディレクトリを設定
if [ -n "$CWD" ]; then
    export CLAUDE_PROJECT_DIR="$CWD"
    cd "$CWD" 2&gt;/dev/null || true
fi

# トランスクリプトファイルが存在する場合、スラッシュコマンドを実行
if [ -n "$TRANSCRIPT_PATH" ] &amp;&amp; [ -f "$TRANSCRIPT_PATH" ]; then
    log_info "Starting Claude Code with /summarize-worklog command (background)..."

    SUMMARIZE_LOG="/tmp/summarize-worklog-$(date +%Y%m%d-%H%M%S)-$$.log"

    # バックグラウンドでClaude Codeを起動
    nohup claude --dangerously-skip-permissions --print "/summarize-worklog $TRANSCRIPT_PATH" &gt; "$SUMMARIZE_LOG" 2&gt;&amp;1 &amp;
    CLAUDE_PID=$!

    log_info "Claude Code started with PID: $CLAUDE_PID"
    log_info "Output log: $SUMMARIZE_LOG"
else
    log_error "No transcript file available for summarization"
fi

echo "✅ Session recorded: worklog generation in progress"
echo "📊 Hook Details: Event=$HOOK_EVENT_NAME"

</code></pre><h3 id="h490085bec7">5. スラッシュコマンド（<a href="http://summarize-worklog.md/" target="_blank" rel="noopener noreferrer">summarize-worklog.md</a>）</h3><p><code>.claude/commands/summarize-worklog.md</code>を作成します：</p><pre><code># 作業記録要約コマンド

トランスクリプトファイルを分析して作業記録を生成し、worklog.mdに追記してください。

## 引数
- トランスクリプトファイルのパス: `$ARGUMENTS`

## 実行手順

1. **トランスクリプトファイルの読み込み**
   - 指定されたJSONLファイルを読み込む
   - ファイルが存在しない場合はエラーを報告

2. **会話内容の分析**
   - JSONLから会話メッセージを抽出
   - ユーザーとアシスタントのやり取りを把握
   - 実施された作業、決定事項、継続タスクを特定

3. **作業記録の生成**
   以下の形式で作業記録を生成:

   ```markdown
   ## YYYY-MM-DD HH:MM - HH:MM - {作業タイトル}

   ### セッション概要
   - **作業内容**: {主要な作業の要約}

   ### 実施作業
   - {詳細な作業内容}
   - {決定事項と根拠}

   ### 重要判断・方針決定
   - {技術判断とその根拠}

   ### 継続タスク
   - {未完了の作業項目}

</code></pre><ul><li><strong>worklog.mdへの追記</strong><code>docs/worklog/worklog.md</code> に生成した作業記録を追記</li><li>追記が完了したらユーザーに報告</li></ul><p><br></p>

<h2 id="hece9b95f2a">開発の試行錯誤</h2>

<p>この機能を開発する過程で、いくつかの壁にぶつかりました。</p><h3 id="h56747f2d11">Phase 1: 初期実装と問題発生</h3><p>最初のアプローチは、フック内で直接<code>claude -p</code>（パイプモード）を使ってAPIを叩く方式でした。</p><pre><code># 初期の実装（問題あり）
echo "$PROMPT" | claude -p --output-format json

</code></pre><p>しかし、以下の問題が発生しました：</p><ul><li><strong>jqコマンド依存</strong>：JSON解析にjqを使っていたが、環境によってはインストールされていない</li><li><strong>bash互換性問題</strong>：一部の構文がmacOS標準のbashで動作しない</li><li><strong>文字エンコーディングエラー</strong>：日本語プロンプトでエラーが発生</li></ul><h3 id="hc6039ae8bf">Phase 2: 大規模トランスクリプトでのタイムアウト</h3><p>上記の問題を解決した後、別の問題が発生しました。長時間のセッション後に生成されたトランスクリプトが<strong>909KB</strong>にも達し、APIがタイムアウトしてしまったのです。<br>この時点で「今のやり方では実現できない」という実感がありました。<br>解決方法を探す中で、スラッシュコマンド方式の存在を知りました。同時にAgent Skills（サブエージェント）という選択肢も検討しましたが、以下の理由からスラッシュコマンドを採用しました：</p><ul><li><strong>Agent Skills</strong>：自動トリガーされる機能で、条件に合致すると自動的にコンテキストに読み込まれる。便利だが、今回の用途では不要なタイミングでもコンテキストを消費する可能性がある</li><li><strong>スラッシュコマンド</strong>：明示的に呼び出す方式で、使用しない限りコンテキストを消費しない</li></ul><p>作業記録生成は特定のイベント（圧縮前・セッション終了時）でのみ実行したい処理です。Agent Skillsの自動トリガーは必要なく、むしろコンテキストウィンドウの限界を解決するための機能が、逆にコンテキストを圧迫しては本末転倒です。<br>この判断が、スラッシュコマンド方式への転換を後押ししました。</p><h3 id="h5ebd13d116">Phase 3: スラッシュコマンド方式への転換</h3><p>スラッシュコマンド方式に切り替えることで、大規模トランスクリプトの問題を解決できました。<br>しかし、今度は<strong>権限問題</strong>が発生しました。バックグラウンドで起動したClaude Codeがファイル読み込み権限の確認でブロックされ、処理が停止してしまいます。<br>最終的に<code>--dangerously-skip-permissions</code>オプションを追加することで解決しました。名前に"dangerously"とありますが、自プロジェクトの作業記録生成という限定的な用途では、リスクは低いと判断しました。</p><h3 id="ha2bdc14bf9">ドキュメントにない仕様との格闘</h3><p>開発中、ドキュメントに記載されていない仕様にも苦しめられました。<br>例えば、<code>PreCompact</code>フックのmatcher設定では、<code>"*"</code>（ワイルドカード）が効かず、<code>"manual|auto"</code>と明示的に指定する必要がありました。<br>これらの問題は、AIに原因調査から修正方法まで考えさせることで解決しました。AI駆動開発の課題をAI駆動開発で解決する、という構図です。</p><h2 id="ha5bdfee356">実際に生成された作業記録</h2><p>以下は、本機能によって実際に自動生成された作業記録の一部です。</p><pre><code>## 2025-11-21 - 作業記録自動作成機能の問題分析と改善方針決定

### セッション概要
- **作業内容**: PreCompactフックのmatcher問題修正、大規模トランスクリプト問題の分析

### 実施作業

#### 1. PreCompactフックのmatcher問題修正
- **問題**: `/compact`実行後にPreCompactフックが動作しない
- **原因特定**: PreCompact/PostCompactイベントは特殊なmatcher仕様
  - SessionEnd等: `"*"`（ワイルドカード）で動作
  - PreCompact: `"manual"` または `"auto"` **のみ**を受け付ける
- **修正内容**: `.claude/settings.json`のPreCompactのmatcherを`"*"` → `"manual|auto"`に変更
- **結果**: 修正後の動作検証成功

#### 2. 大規模トランスクリプト問題の分析
- **問題発生**: 自動圧縮でフックが処理途中で停止
- **ログ分析結果**:
  - トランスクリプトサイズ: **909,127 bytes**（通常の25-60倍）
  - Claude API呼び出し: 開始後に応答なし（タイムアウト）
- **原因**: 大規模トランスクリプトをそのままAPIに送信し、タイムアウトが発生

### 重要判断・方針決定
- **PreCompact/PostCompactの特殊仕様**: matcherは`"manual|auto"`が必要（`"*"`は不可）
- **API呼び出し方式の変更**: `claude -p` → Claude Code新規起動方式へ移行決定

### 質疑応答・ナレッジ創出
**Q**: なぜClaude APIを直接呼び出すとタイムアウトするのか？
**A**: `claude -p`（パイプモード）は大きなプロンプトに対する制限があり、909KBのトランスクリプトはAPI側でタイムアウトに引っかかる

</code></pre><p>このように、実施した作業、発生した問題とその原因、技術的な判断とその根拠が自動的に記録されます。</p>

<h2 id="hb83b45066b">導入効果と副次的な発見</h2>

<h3 id="hc0ee609b66">当初の目的：コンテキスト消失への備え</h3><p>本機能の導入効果については、まだ実感としては薄い段階です。これから実際の開発で使い込んでいく中で、効果を検証していく予定です。</p><h3 id="h68152a47f1">副次的な発見：ナレッジ共有への応用</h3><p>実は、この機能を開発する過程で、予想外の発見がありました。<br>実際に取得できた作業記録を見たとき、「これ、ナレッジ共有に使えるじゃん」と気づいたのです。<br>元々、モデル開発のナレッジをどう共有するかという課題感を持っていました。成功例や失敗例を組織的に蓄積・活用したいと考えていたのですが、具体的な方法が見えていませんでした。<br>作業記録には、以下のような情報が含まれています：</p><ul><li>実施した作業の詳細</li><li>技術判断とその根拠</li><li>発生した問題と解決方法</li></ul><p>これらの情報が自動的に蓄積されるなら、複数プロジェクトの知見を横断的に検索・活用できる可能性があります。</p>

<h2 id="hadb92af0e7">将来の展望：モデル開発エージェントへ</h2>

<h3 id="he1f1e43550">ナレッジ共有の構想</h3><p>私たちは今後、複数のモデル開発プロジェクトが開始時期もバラバラに、並行して走る状況を想定しています。その際、AIが作業記録を横断検索して最新の情報を取得できるようになると考えています。<br>具体的には、以下のアプローチを検討しています：<br><strong>1. GitHub MCP方式</strong><br>作業記録をGit管理し、GitHubにプッシュした上で、GitHub公式MCPサーバーを接続する方式です。<br>この方式の最大の利点は、作業記録だけでなく、関連するソースコードや設計ドキュメントも同時に取得できることです。GitHub MCPサーバーはリポジトリ内のファイル読み取り、コード検索、コミット分析などの機能を提供しており、AIが「この作業記録に関連するコードを見せて」といった形で情報を取得できます。<br>追加のインフラ構築が不要で、既存のGit/GitHubワークフローに自然に統合できる点も魅力です。<br><strong>2. 専用MCPサーバ方式</strong><br>Model Context Protocol（MCP）は、LLMが外部データソースにアクセスするための標準プロトコルです。作業記録を専用のMCPサーバとして公開することで、Claude Codeや他のMCP対応ツールから直接検索・参照できるようになります。<br>GitHub方式と比べて、より柔軟な検索ロジックやフィルタリングを実装できる可能性があります。<br><strong>3. RAG方式</strong><br>Retrieval-Augmented Generation（RAG）は、外部知識ベースから関連情報を検索してLLMに提供する手法です。作業記録をベクトルデータベースに格納し、質問に関連する記録を自動で取得してコンテキストに追加します。<br>セマンティック検索により、キーワードが完全一致しなくても関連する記録を取得できる点が強みです。<br><br>どの方式を採用するかは、今後の検証で決めていく予定です。いずれの方式でも、AIが能動的にナレッジを検索・活用できるようになります。これにより：</p><ul><li><strong>トライアンドエラーの精度向上</strong>：成功例や失敗例を簡単に取得できる</li><li><strong>人に依存しない知識共有</strong>：発信の得手不得手や、共有要否の判断によるブレをなくす</li><li><strong>外注時のナレッジ回収</strong>：仮にモデル開発を外注しても、ナレッジを組織に蓄積できる</li></ul><h3 id="hfa2a470d1d">目指す成果</h3><p><strong>まず実現したいこと</strong>は、モデル開発の効率化による提供スピードの短縮と費用の圧縮です。<br>また、<strong>ジュニアエンジニアの早期戦力化</strong>も重要な目標です。過去の作業記録から成功パターンや失敗パターンをAIが自動で参照できるようになれば、経験の浅いエンジニアでも、ベテランの知見を活用しながら開発を進められます。「入社してすぐに実戦投入」というハードルを大きく下げられると考えています。<br><strong>その先に見据えているもの</strong>は、モデル開発エージェントへの発展です。作業記録から学習したナレッジを活用し、より自律的にモデル開発を進められるAIエージェントを構築したいと考えています。<br>実現時期としては、まだ構想段階ですが、2026年初頭には取りかかりたいと考えています。その前に、作業記録の蓄積と適正化を進める必要があります。</p>

<h2 id="h9be0c3393d">おわりに</h2><p>AI駆動開発を実践する中で、コンテキストウィンドウの限界という壁にぶつかりました。しかし、その課題自体もAI駆動開発で解決できることがわかりました。<br>今回紹介した作業記録自動作成機能は、まだ発展途上です。これから実際の開発で使い込みながら、改善を続けていく予定です。<br>AIツールは急速に進化しています。今回紹介した方法も、将来的にはClaude Code自体の機能として取り込まれるかもしれません。しかし、現時点でできることを試行錯誤しながら形にしていくプロセス自体が、急速に進化するAIと協働する面白さだと感じています。<br>AIを活用した開発に興味のある方、一緒に試行錯誤しながら新しい可能性を模索していきませんか？Azitでは、物流・SCM領域の課題解決に取り組む仲間を募集しています。<br>最後まで読んでいただき、ありがとうございました。</p>

コンテキストウィンドウの限界を解決するClaude Code Hooks活用術

<h2 id="h8d027c8ed3">はじめに</h2><p>株式会社Azitでエンジニアリングマネージャーをしている岩瀬です。<br>前回の記事「<a href="https://love-from.azit.co.jp/article/forecast-modeling-with-ai" target="_blank" rel="noopener noreferrer">AIを活用した需給予測モデル開発で学んだこと</a>」では、バイブコーディングでの開発体験と失敗から得た教訓について書きました。今回は、その経験を踏まえて、私たちAzitが今後どのようにAI駆動開発を進めていきたいかについて紹介します。<br>ここで紹介するAI駆動開発は、今後ForecastXの需給予測モデル開発に採用予定の手法です。体系的なAI活用開発手法を模索されている方の参考になれば幸いです。</p>

<h2 id="h5e4b431bb5">バイブコーディングからAI駆動開発へ</h2><p><img src="https://images.microcms-assets.io/assets/d4e25007543940f0849c6e5f6c46811d/28027e14566c49428415a534b4fbfcdf/%E3%83%8F%E3%82%99%E3%82%A4%E3%83%95%E3%82%99%E3%82%B3%E3%83%BC%E3%83%86%E3%82%99%E3%82%A3%E3%83%B3%E3%82%AF%E3%82%99%E3%81%8B%E3%82%89AI%E9%A7%86%E5%8B%95%E9%96%8B%E7%99%BA%E3%81%B8.png?w=800&amp;h=533" alt=""></p><h3 id="hdf4b15b372">用語の整理</h3><p>まず、この記事で使用する用語は比較的新しい言葉なので、文章中での意味を明確にしておきます。<br><strong>バイブコーディング：</strong> AI研究者アンドレイ・カルパシーが提唱した開発手法で、「雰囲気（Vibe）を伝えるだけで、AIがコードを生成する」アプローチです。開発者は自然言語でざっくりとした要望を伝え、AIに実装を「委ねる」ことで、詳細な仕様よりも「望ましい結果」を重視します。<br><strong>Azitが目指すAI駆動開発：</strong> 私たちのアプローチでは、人間がプロジェクトマネジメントに徹し、AIがシステム開発の実務部分（要件定義、設計、実装、テスト、保守運用）を担う役割分担を想定しています。一般的なプロジェクト管理や開発手法をベースに、AIとの協働を体系化した開発手法です。<br>なお、AI駆動開発は比較的新しい概念で、まだ業界全体で統一された定義は確立されていません。企業や組織によって、AIの活用範囲や人間との役割分担についての解釈が異なるのが現状です。</p>

<h3 id="hf1240d8cdb">なぜAI駆動開発が必要なのか</h3><p>前回の記事で詳しく説明したように、バイブコーディングには多くの課題があります。特に以下の点で限界を感じました。<br><strong>品質の課題：</strong> バイブコーディングでは、その場しのぎの指示により、全体設計が欠如し、保守性の低いコードが大量生成されます。修正が必要になった際も、どこをどう修正すべきかわからない状況に陥りやすく、適切な品質管理ができません。<br><strong>再現性の課題：</strong> 計画性のない開発では、同じような要求に対して毎回異なるアプローチを取ってしまい、ナレッジの蓄積や標準化が困難です。また、開発プロセスが属人化してしまい、チームでの知識共有も難しくなります。<br><strong>スケーラビリティの課題：</strong> バイブコーディングは個人レベルでは機能しますが、チーム開発や大規模プロジェクトでは破綻します。複数人で開発する際の役割分担や、品質基準の統一ができません。<br>これらの課題を解決するために、私たちはAI駆動開発への移行を目指しています。</p>

<h2 id="h09bf284530">Azitが考えるAI駆動開発の体制</h2><p><img src="https://images.microcms-assets.io/assets/d4e25007543940f0849c6e5f6c46811d/668b1d7e37b04712ae04cb1d91a078de/Azit%E3%81%8B%E3%82%99%E8%80%83%E3%81%88%E3%82%8BAI%E9%A7%86%E5%8B%95%E9%96%8B%E7%99%BA%E3%81%AE%E4%BD%93%E5%88%B6.png?w=800&amp;h=533" alt=""></p><h3 id="h84750cae35">役割分担の明確化</h3><p>AI駆動開発では、人間が意思決定を、AIが実行をそれぞれ担当するという役割分担で行います。<br>人間は要求整理、プロジェクトマネジメント、戦略決定と方針策定、品質管理と評価、AIへの指示とコントロール、最終的な判断と承認といった意思決定に関わる業務を担います。<br>一方、AIは要件定義と仕様策定、設計と技術選択、コード実装、テスト設計と実行、ドキュメント作成、保守運用支援といったシステム開発の実行業務を担当します。</p><h3 id="h417e7428c3">計画的な開発プロセスの採用</h3><p>AI駆動開発では、バイブコーディングの即興性から脱却するため、段階的な開発プロセスを採用します。要件定義から実装まで、計画的に段階を経て進めることで、品質と再現性を確保します。<br><strong>フェーズ1：データ分析</strong> 現状の調査から始まり、業務フローやデータの分析と課題の抽出を経て、関係者の要求を整理します。<br><strong>フェーズ2：要件定義・設計</strong> 分析・要求整理の結果を基に要件を定義し、技術選択や実装方針を策定します。その後、機能一覧やシステムフロー、クラス設計といった詳細設計を行い、開発計画を立案します。<br><strong>フェーズ3：実装</strong> テスト作成から始まり、設計に基づいたコード実装、テストとレビューを経て、開発計画の更新まで行います。<br><strong>フェーズ4：リファクタリング</strong> 改善点の調査とリファクタリング計画を立て、コード品質の向上とドキュメント整備を実施します。</p>

<h2 id="he57fe85aa8">AI駆動開発でのTDD活用</h2><h3 id="h331f28781a">テスト駆動開発の採用</h3><p>私たちのAI駆動開発では、実装フェーズでテスト駆動開発（TDD）を採用予定です。従来のTDDでは、テストコードの記述に時間がかかり、開発速度が低下するデメリットがありましたが、AI駆動開発ではこの課題を解決できると考えています。</p><h3 id="h47e536033a">AI活用によるTDDのメリット</h3><p><strong>開発速度の向上：</strong> AIがテストコードを高速で生成するため、従来のTDDで問題となっていたコード量増加による開発時間の延長を大幅に短縮できます。<br><strong>網羅的なテストケースの自動生成：</strong> 設計仕様からAIが自動的に網羅的なテストケースを生成し、実装者が考慮し切れないエッジケースや境界値テスト、異常系のテストケースまで体系的にカバーできます。<br><strong>リファクタリング時の安全性向上：</strong> 充実したテストスイートがAIによって迅速に構築されるため、後のリファクタリング作業において安心してコード改善を行えます。<br>これらの利点により、AI駆動開発ではTDDの恩恵を最大限に享受しながら、従来の課題を克服できると期待しています。</p>

<h2 id="h4a510a2321">開発記録の体系化</h2><h3 id="h7b59641c80">開発記録のテキスト化</h3><p>AI駆動開発において重要なのは、開発の記録をテキストで残すことです。AIには人のような記憶がないため、継続的な協働には明示的な記録が必要です。<br>記録すべき内容として、要求と仕様の変更履歴、技術選択の理由と根拠、実装方針と設計判断、発生した問題と解決方法、テスト結果と品質指標、リファクタリングの内容と効果などがあります。<br>私たちは現在、議事録ファイル（プロジェクト全体の経緯）、開発計画書（タスクの進捗と完了記録）、技術判断記録（重要な判断の理由と背景）、振り返りレポート（各フェーズでの学びと改善点）といった形式での記録を試行しています。</p><h3 id="h685ea2713a">ナレッジの蓄積と再利用</h3><p>将来的には、蓄積された開発記録を他のプロジェクトでも活用できるようになればと考えています。よくある課題パターンとその解決方法、効果的だったプロンプトの使用場面、品質チェックのポイントやリファクタリングのベストプラクティスなどが蓄積されれば、開発効率がさらに向上するかもしれません。</p>

<h2 id="hfd9fa54a8a">具体的な開発テンプレートの紹介</h2><h3 id="h34b35a4749">開発テンプレートの構成</h3><p>私たちは現在、ForecastXでの予測モデル開発に向けて、体系化された開発テンプレートを準備しています。<br><strong>ディレクトリ構成：</strong></p><pre><code>model-development-templates/
├── src/&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; # ソースコード
│&nbsp; &nbsp;├── forecasters/&nbsp; &nbsp; &nbsp; &nbsp;# 予測エンジン
│&nbsp; &nbsp;└── utils/&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; # ユーティリティ
├── tests/&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;# テストコード
├── input/&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; # インプットデータ
├── output/&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;# 予測結果
├── doc/&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; # ドキュメント
│&nbsp; &nbsp;├── templates/&nbsp; &nbsp; &nbsp; &nbsp; # テンプレート集
│&nbsp; &nbsp;├── reports/&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; # 調査報告
│&nbsp; &nbsp;└── pronpts/&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; # 段階別プロンプト集
└── temp/&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;# 調査・検証用スクリプト</code></pre>

<h3 id="h5099819aca">段階別プロンプト集</h3><p>開発の各段階に対応したプロンプトを用意しています：<br><strong>データ分析段階：</strong></p><ul><li>データ分析1：基本統計とデータ品質確認</li><li>データ分析2：販売パターンの分析</li><li>データ分析3：季節性・トレンド分析</li><li>データ分析4：異常値・外れ値の検出</li><li>データ分析5：予測手法選択のための特徴抽出</li></ul><p><strong>設計段階：</strong></p><ul><li>機能一覧作成：要求から機能への分解</li><li>システムフロー設計：処理の流れと依存関係</li><li>クラス設計：詳細な実装仕様の策定</li></ul><p><strong>実装段階：</strong></p><ul><li>テスト作成：先にテストコードを生成</li><li>コード実装：設計に基づく実装</li><li>テストとレビュー：品質チェック</li><li>計画更新：進捗と次タスクの管理</li></ul><p><strong>リファクタリング段階：</strong></p><ul><li>調査：改善点の洗い出し</li><li>計画：リファクタリング方針の策定</li><li>実装：実際の改善作業</li></ul><h3 id="h18e2a80384">ドキュメントテンプレート集</h3><p>各段階で作成するドキュメントのテンプレートも整備しています：</p><ul><li>モデル開発時のClaude設定ファイル</li><li>データ分析レポートのフォーマット</li><li>要求整理書のテンプレート</li><li>システムフロー設計書のフォーマット</li><li>クラス設計書のテンプレート</li><li>開発計画書のフォーマット</li></ul><p>これらのテンプレートにより、AIが自由に設計し開発を進めることを抑制できると期待しています。</p><h3 id="h9cbc112489">テンプレート活用の効果</h3><p>このようなテンプレート化により、毎回ゼロから考える必要がなくなり、過去の経験やベストプラクティスを再利用して品質の標準化と向上を図れます。また、抜け漏れの防止と一貫した開発プロセスの実現により、段階的な品質チェックが可能になります。<br>さらに、チーム内でのノウハウ共有が促進され、新メンバーの早期戦力化と組織的な学習の促進も期待できます。</p>

<h2 id="h9d43282b60">今後の取り組みと展望</h2><p><img src="https://images.microcms-assets.io/assets/d4e25007543940f0849c6e5f6c46811d/d6e765b4efc342e6b27b8e9213094d91/%E4%BB%8A%E5%BE%8C%E3%81%AE%E5%8F%96%E3%82%8A%E7%B5%84%E3%81%BF%E3%81%A8%E5%B1%95%E6%9C%9B.png?w=800&amp;h=533" alt=""><br>私たちは年内（2025年内）に、ForecastXの予測モデル開発でAI駆動開発手法を本格導入することを目標としています。そのために、開発テンプレートの実戦投入と改善、開発記録の体系化手法の確立、チーム内でのナレッジ共有システムの構築、品質指標と評価基準の策定に取り組んでいます。<br>AI駆動開発は一度確立すれば終わりではありません。AIツールの進化やプロジェクトの経験を通じて、プロンプトの効果測定と最適化、新しいAIツールの評価と導入、開発プロセスの効率化、品質管理手法の向上を継続的に行っていく必要があります。<br>現在は個人やプロジェクトレベルでの試行錯誤ですが、将来的には組織全体でのAI駆動開発の標準化を目指しています。エンジニアの育成とスキル向上、開発体制の最適化、外部パートナーとの協業、業界全体への知見共有といった課題にも取り組んでいく予定です。</p>

<h2 id="h9be0c3393d">おわりに</h2><p>AI駆動開発は、AIツールの急速な進化と共に、まだまだ発展途上の分野です。私たちAzitでも試行錯誤を続けながら、最適な開発手法を模索している段階です。<br>前回の記事で紹介したバイブコーディングでの失敗体験も、AI駆動開発という新しいアプローチを見つけるための重要なステップでした。失敗から学んだ教訓を活かし、より効率的で質の高い開発手法を確立していきたいと考えています。<br>AI駆動開発の可能性は非常に大きく、適切にアプローチすれば従来では困難だった速度と質での開発が実現できると確信しています。しかし、その実現には技術的な工夫だけでなく、組織的な取り組みや継続的な改善が必要です。<br>こうした新しい開発手法に興味を持ってくださる方と一緒に働けたら嬉しいと思っています。AI駆動開発の未来を一緒に模索し、物流・SCM領域の課題解決に取り組んでいきましょう。<br>最後まで読んでいただき、ありがとうございました。</p>

需給予測モデル開発で実践するAI駆動開発

<h2 id="h8d027c8ed3">はじめに</h2><p>株式会社Azitでエンジニアリングマネージャーをしている岩瀬です。<br>私たちは物流・SCM領域に特化したAIソリューションを提供しており、2025年9月に需給予測プラットフォーム「ForecastX」をリリースしました。プラットフォームの開発と並行して、ForecastXに搭載する個社別の予測モデルについて、開発手法の確立に取り組んでいます。<br>今回は、ECサイトの需給予測モデル開発プロジェクトについて振り返ってみたいと思います。<br>このプロジェクトでは、Claude Codeを中心としたAIツールを活用して開発を進めました。結果として目標は達成できたものの、途中で大きな失敗を経験し、多くの学びを得ることができました。特に、開発における落とし穴や、より良い開発手法について考える良い機会となりました。<br>需給予測やデータサイエンス領域でのAI活用開発を検討されている方に、実際の体験談として参考にしていただければと思います。</p>

<h2 id="h3af4d147a9">プロジェクト概要</h2><h3 id="h84e47269a9">お客様の課題</h3><p>今回のお客様はECサイトを運営されており、自社商品の需給予測に課題を抱えていました。<br><strong>既存の予測方法：</strong></p><ul><li>1週間ごとに、過去7日間の平均販売数×30日間で需要を予測</li><li>その結果を人が確認して手作業で補正</li></ul><p><strong>抱えている問題：</strong></p><ul><li>毎週5名の担当者が各3時間、合計15-20時間を予測作業に費やしている</li><li>過剰在庫や欠品が頻繁に発生している</li></ul><h3 id="hc3c727994d">開発目標と条件</h3><p>私たちの開発目標は、毎週の予測にかかる工数を大幅に削減し、既存の予測よりも精度を向上させることで、間接的に過剰在庫や欠品の発生を抑制することでした。<br><strong>開発条件：</strong></p><ul><li>予測期間：30日間</li><li>予測単位：SKU単位（商品よりも細かい単位）</li><li>出力：販売数上位500SKUの予測</li><li>重視する需要変動要因：季節性イベント、販促期間</li><li>開発手法：Claude Codeを用いたバイブコーディング</li></ul><p>このプロジェクトは社内検証も兼ねており、ジュニアや非エンジニアでもAIを活用した開発ができるかを検証する目的もありました。</p>

<h2 id="h5868b42986">Phase1での試行錯誤と失敗</h2><p><img src="https://images.microcms-assets.io/assets/d4e25007543940f0849c6e5f6c46811d/f14cb80bb1784aeb960fdb7b3c436b9c/Phase1%E3%81%A6%E3%82%99%E3%81%AE%E8%A9%A6%E8%A1%8C%E9%8C%AF%E8%AA%A4%E3%81%A8%E5%A4%B1%E6%95%97.png?w=800&amp;h=533" alt=""></p><h3 id="h201a830600">初期のアプローチ</h3><p>Phase1では、以下の前提で開発をスタートしました。<br><strong>技術的前提：</strong></p><ul><li>予測手法はProphet（Meta社製）を使用</li><li>イベントの影響はパラメータで指定</li><li>予測精度を測る指標はRMSEを採用</li></ul><p><strong>開発手法：</strong></p><ul><li>Claude Codeを使ったバイブコーディング</li><li>その場その場で思いついた指示を口語で出す</li><li>明確な開発計画なし</li></ul><h3 id="hf58b5ccdcd">一見良好だった結果</h3><p>Phase1の結果は、表面的には非常に良好でした。販売数上位500SKUのうち大多数でRMSEの値が5以下という指標上の精度を示し、予測処理も数分で完了するようになりました。当初は「うまくいった」と感じていました。</p><h3 id="hc02df7f74c">問題の発覚と衝撃</h3><p>しかし、問題が明らかになったのは、お客様からの指摘でした。<br>「実際の販売数と予測数に大きな乖離があるのですが...」<br>この言葉を聞いた時の衝撃は今でも忘れられません。改めて結果を確認すると、確かに予測と販売実績の誤差は、私たちのスクリプトによる予測とお客様による予測で、それほど差がありませんでした。RMSEの数値は良いのに、実際のビジネス要求には応えられていなかったのです。</p><h3 id="h5368c834ab">根本原因の分析</h3><p>お客様の指摘を受けて原因を深掘りした結果、複数の根本的な問題が明らかになりました。<br><strong>1. 予測手法の選択ミス</strong><br>Prophetは毎日安定して売れている商品で、1〜2年程度の販売実績がある場合に威力を発揮します。しかし、お客様の商品は間欠需要（販売実績が0の日が続く）が主体でした。つまり、商品の販売パターンがProphetの前提条件に合っていなかったのです。<br><strong>2. 指標選択の問題</strong><br>RMSEは販売数量が少ないと数値が低く出やすく、「精度が良い」と誤認しやすい構造的な問題を抱えています。私たちは技術的な指標に満足してしまい、実際のビジネス要求との乖離に気づけませんでした。<br><strong>3. データの理解不足</strong><br>カテゴリ情報が不完全で、販売終了した商品のデータも正確ではない可能性があり、1SKUあたりのデータ履歴も想定より少なかったのです。<br><strong>4. 開発手法の問題</strong><br>バイブコーディングによる計画性のない開発により、全体設計が欠如し、不要な機能や使われない関数が大量に生成されました。スクリプトの品質も悪く、調整による変動なのかバグによる変動なのか判断できない状況でした。</p><h3 id="hdd9987ed50">バイブコーディングの限界</h3><p>この失敗を通じて、バイブコーディングの限界も明確になりました。<br>お客様の指摘を受けてから修正を試みましたが、バイブコーディングで作られたコードでは適切な修正ができませんでした。パラメータ調整を試みても思ったように予測値が変化せず、全体で予測値が狂っていくような状況でした。また、予測値について抑制や補正の機能を追加しようとしたところ、使われていない関数を修正したことで動作しなくなるなど、適切に調整できない、修正箇所がわからないといった状態に陥りました。<br>実装方針の一貫性がなく、デバッグやメンテナンスが困難になっていたのです。何より問題だったのは、「動くものができた」という達成感に満足してしまい、本質的な問題への気づきが遅れたことです。</p>

<h2 id="hf5eb1f57a4">Phase2での改善と学び</h2><p><img src="https://images.microcms-assets.io/assets/d4e25007543940f0849c6e5f6c46811d/733c6f527aed438d88ce3c7a9bea5643/Phase2%E3%81%A6%E3%82%99%E3%81%AE%E6%94%B9%E5%96%84%E3%81%A8%E5%AD%A6%E3%81%B2%E3%82%99.png?w=800&amp;h=533" alt=""></p><h3 id="hd2d1af3a14">アプローチの根本的見直し</h3><p>Phase2では、Phase1の失敗を踏まえて抜本的に改善しました。<br><strong>技術的改善：</strong></p><ul><li>予測手法をProphetに固定しない</li><li>予測精度はCVRMSEと予測と実績の絶対誤差で評価</li><li>販売実績データの特徴から4つのグループに分類し、それぞれに最適な予測手法を適用</li></ul><p><strong>使用手法：</strong></p><ul><li>MSTL+ETS</li><li>Croston法</li><li>Prophet</li></ul><p>販売パターンを解析し、間欠需要、新商品、在庫制約、多重季節性などの特徴に応じて手法を使い分けるアプローチに変更しました。</p><h3 id="hd695bd9d12">計画的な開発プロセスの導入</h3><p>開発手法においても大きな改善を行いました。バイブコーディングから脱却し、計画的な開発プロセスを導入しました。<br><strong>計画的な開発プロセス：</strong></p><ol><li>事前の開発計画策定</li><li>簡易設計書の作成</li><li>実装前の認識合わせ</li><li>コードレビューの実施</li><li>リファクタリングの組み込み</li></ol><p><strong>AIツールの効果的な活用：</strong></p><ul><li>Claude Code：実装作業</li><li>ChatGPT：コードレビュー</li></ul><h3 id="h62ab4e6eec">レビューフローの確立</h3><p>効率的なレビューフローも確立しました。<br><strong>レビューフロー：</strong></p><ol><li>ChatGPTにコードや出力を渡してレビューを実施</li><li>レビュー内容をマークダウンファイルに出力</li><li>Claude Codeで読み込み、レビュー内容について質問を生成</li><li>質問をChatGPTに渡して質疑応答</li><li>Claude Codeで実装方法を検討</li><li>開発計画にタスクを追加</li><li>修正や調整の実施</li></ol><p>このフローにより、AIツール間での知識共有と品質向上を実現できました。</p><h3 id="h863c82052d">データドリブンな改善</h3><p>技術面では、様々な補正機能を追加しました。<br><strong>補正機能の追加：</strong></p><ul><li>カテゴリ情報による傾向補正</li><li>イベント影響度の期間とカテゴリ別調整</li><li>異常値の抑制機能</li><li>イベント専用品の期間外除外</li></ul><p><strong>データ品質の向上：</strong></p><ul><li>学習対象を販売数上位1000SKUに拡大</li><li>直近販売実績による対象絞り込み</li><li>終売データと販売実績の整合性確認</li><li>出力を予測数上位500SKUに変更</li></ul><h2 id="hfbdae7ba67">開発結果と成果</h2><p>Phase2での改善により、大きな成果を得ることができました。<br><strong>精度面での成果：</strong></p><ul><li>CVRMSEと絶対誤差ともに、お客様の予測手法を上回る結果</li><li>5つの重要イベント全期間で、お客様の予測より誤差を削減</li><li>予測の当たり外れとSKUの特徴に相関が見られるように</li></ul><p><strong>運用面での成果：</strong></p><ul><li>販売数上位1000SKUの学習と予測数上位500SKUの出力を約6分で完了</li><li>パラメータ調整で期待通りに結果が変わるように</li><li>大きな外れを抑制しつつ予測精度を底上げ</li></ul><p><strong>開発プロセスの改善：</strong></p><ul><li>再現可能で保守しやすいコード</li><li>明確な設計思想と実装方針</li><li>効率的なレビューサイクル</li></ul><p><br></p>

<h2 id="h68c92673e9">需給予測モデル開発で学んだ教訓</h2><p><img src="https://images.microcms-assets.io/assets/d4e25007543940f0849c6e5f6c46811d/263d23766c0345cdaabd934a52a361e8/%E9%9C%80%E7%B5%A6%E4%BA%88%E6%B8%AC%E3%83%A2%E3%83%86%E3%82%99%E3%83%AB%E9%96%8B%E7%99%BA%E3%81%A6%E3%82%99%E5%AD%A6%E3%82%93%E3%81%9F%E3%82%99%E6%95%99%E8%A8%93.png?w=600&amp;h=600" alt=""><br>このプロジェクトを通じて得た教訓をまとめます。</p><h3 id="h98c8528915">1. データ理解の重要性</h3><p>最も重要な学びは、モデル開発前にデータを十分に精査するフェーズが必要だということです。データの物量だけでなく、質（完全性）と予測単位での状態把握が重要であることを痛感しました。<br>今回のプロジェクトでは、履歴が長くても安定した販売実績のないデータの予測は難しいということも学びました。間欠需要に対する要因分析（偶然売れたのか、セールによるものか）や、外部要因（賞味期限、セール情報）の整備が必要です。</p><h3 id="h9489050ea4">2. 指標選択の重要性</h3><p>技術的な指標と業務要求の乖離に注意が必要であることも大きな学びでした。「精度が良い」という状態について、顧客との共通認識を持つことが重要です。<br>RMSEのような技術的な指標だけでなく、ビジネス要求に直結する指標を選択することの重要性を学びました。顧客の解決したい問題から逆算した指標設定、現行手法との比較による目標値設定、見切り条件の事前合意が必要です。</p><h3 id="h6641aae22d">3. 計画的開発手法の必要性</h3><p>バイブコーディングでは品質確保が困難であることも明確になりました。一般的なプロジェクト管理手法を導入することで、開発効率と品質が大幅に向上することを実感しました。<br>特に、販売実績データの状態から逆算して予測手法を選択することや、予測手法だけではなく傾向から係数で補正をかけることは、調整がしやすく非常に有効でした。</p><h3 id="h49fa0fb52e">4. AIツールの適切な活用</h3><p>AIツールは非常に強力ですが、適切な制御と組み合わせが重要であることも学びました。複数AIツールの役割分担、構造化されたレビューフロー、開発記録の体系化により、AIの能力を最大限に活用できることがわかりました。<br>特に、開発の記録をテキストで残すことは、AIとの継続的な協働において非常に重要です。AIには人のような記憶がないため、人がやる以上にドキュメントを残すことが必要であることを実感しました。</p>

<h2 id="h9be0c3393d">おわりに</h2><p>今回のプロジェクトは、技術的な成果だけでなく、AI開発の新しい可能性と課題を見出す貴重な経験となりました。失敗から学んだ教訓を活かし、より効率的で質の高いAIを活用した開発手法を確立していきたいと考えています。<br>AIを活用した開発は、従来の開発手法とは異なる新しいスキルセットや考え方が求められる一方で、適切にアプローチすれば従来では困難だった速度と質での開発が可能になります。<br>私たちAzitでは、この経験を踏まえてForecastXをはじめとする製品開発を進めており、AI活用開発の手法をさらに洗練させていく予定です。AIを活用した開発に興味のある方、一緒に新しい開発手法を模索していきたい方は、ぜひお気軽にお声がけください。<br>最後まで読んでいただき、ありがとうございました。</p>

Pick Up!

Hashtags

Latest Articles