トップリバーグループの目指す、生成AI時代のDX
開発体制と内製化の経緯現場変化に追随するため、外注依存ではなく内製を選択
内製化を選んだ理由は、技術を持ちたいからではありません。農業現場、教育、バックオフィスをまたぐ運用では、 要望の粒度が細かく、変化の周期も短いためです。会議で出た論点をそのまま仕様へ落とし込み、試し、修正し続けるために、 近い距離で判断できる体制が必要でした。
システム責任者
全体の要件整理、優先順位付け、設計判断、公開方針の統括
開発体制
現場管理者・運用担当者の使い勝手の確認、例外運用の洗い出し、改善要望のフィードバック
内製開発
AIを活用した構成案・実装案の作成を起点に、画面修正やデータ接続を行いながら、継続的な改善を進めています。
サービス連携
既存システム・外部サービスとの連携（Google Docs、Drive、既存台帳、共有基盤）との接続整理
内製化の流れ
現場の業務を確認し、分断されているポイントを整理する
開発に入る前に、現場で実際に行われている業務の流れを確認し、
情報や判断がどこで途切れているかを整理します。
会議内容が実行に反映されていない、管理が分かれている、といった課題を明確にすることで、改善の対象を定めます。
生成AIを活用し、構造と画面構成を素早く組み立てる
見えてきた課題をもとに、生成AIを活用しながら、
情報構成や画面の設計案を早い段階で具体化します。
短時間で検討材料をそろえ、設計の方向性を共有・検討できる状態をつくることで、次の判断へつなげます。
内製チームで、運用条件・権限・接続関係を具体化する
設計案をもとに、内製チームが実運用を前提とした検討を行います。
利用者ごとの権限設定、例外的な運用、既存システムとの接続関係など、
現場ごとに異なる条件を踏まえて具体化していきます。
現場で使いながら調整し、公開・展開可能な粒度へ整える
実際の現場運用を通じて、操作性や運用上のズレを確認し、修正を重ねます。
理論上の正しさだけでなく、無理なく使い続けられる状態を目指し、社内外に展開できる粒度まで整えていきます
トップリバーアカデミー代表コメント
外注だけでは、見積、発注、確認のサイクルが現場の変化に追いつかない局面が多くありました。 そのため、生成AIで叩き台を速く作りつつ、内製で設計と改善を回す体制に切り替えています。 大切なのは、AIで早く作ることではなく、現場で使い続けられる状態まで責任を持つことです。
システム担当者コメント
PJバインダーも営農アプリ群も、完成品として固定する前提ではありません。 会議、段取り、圃場、整備といった業務の流れを見ながら、必要な画面と機能を細かく内製し、 後から横断活用できるデータとして残るよう整えていく方針です。
内製化の背景
会議の場で出た論点を、そのまま改善対象として扱いたい一方で、従来の外注中心モデルでは小さな修正が積み上がりにくい課題がありました。
切り替えの判断
生成AIを使えば、画面案や処理案の叩き台を短時間で作れます。ただし、それだけでは運用に乗らないため、近い距離で設計判断できる内製体制へ重心を移しています。
現在の考え方
AIは速度を上げる手段、内製化は改善を止めないための手段という位置づけで、両方を一体で進めています。