AI人材・組織

プログラミングの専門知識がなくても2〜3カ月でPythonアプリを完成——JR九州の非IT部門がGeminiで実践した内製開発の進め方

JR九州の運輸部では、プログラミング未経験の担当者がGeminiと対話しながら、車両データ分析と勤務シフト作成のアプリを2〜3カ月で内製しました。公開情報から進め方を整理し、自社で試す前の確認点をチェックリストで示します。

生成AIのGeminiを使って非IT部門がPythonアプリを内製したJR九州の事例を解説する記事のアイキャッチ画像

公開日: 2026年11月13日
カテゴリ: AI人材・組織


この記事の要点

  • JR九州の運輸部企画課で、プログラミングの専門知識を持たない担当者が、生成AI(Gemini)を使って業務アプリ2本を2〜3カ月で内製した。同社の導入事例(Google Workspace公式ブログ)と複数の報道で確認できる
  • コードの9割以上をAIが生成し、担当者は「要件を伝える→コードを確認する→改良を依頼する」というサイクルで開発を進めた
  • この方法は「アプリ開発=エンジニアの仕事」という前提を見直す具体的な根拠になる
  • 自社で試す前に、業務課題の具体性、社内のAI利用ルール、小さく試す範囲、完成後に使い続ける仕組みを確認しておくと進めやすい
  • 「まず試せるか」を判断するためのチェックリストを、この記事の後半で示している

読む前に確認しておきたい言葉

言葉 一言で言うと 身近な例え
PoC(概念実証) 小規模な試し運転 新メニューを全店展開する前に1店舗でテストする
Streamlit Pythonで画面付きWebアプリを作るツール Excelのマクロで集計画面を作るイメージ
内製開発 外注せず自社で作ること 業者に頼まず自社スタッフが販促資料を作る

コードの9割以上をAIが書いた——そのアプリを完成させたのは、エンジニア経験のない現場の担当者でした。

JR九州の事例で参考になるのは、AIの性能そのものよりも、現場の担当者が業務の要件をAIに伝え、出てきたコードを確かめながら仕上げていった進め方です。この記事では、公開情報で確認できる範囲でその進め方を整理し、自社で試すときの確認点をまとめます。


事例の概要

項目 内容
業種 鉄道・運輸(JR九州/九州旅客鉄道)
会社規模 社員数7,738名(2026年4月1日現在、同社の会社概要より)。大企業だが、今回の取り組みは現場の担当者が主体
課題 現場の業務改善の要望をIT部門だけでは受けきれず、外部ベンダーへの委託には費用と時間がかかる
使ったツール Gemini(Google提供の生成AIツール)、Streamlit(Python製のWebアプリ作成ツール)
期間 2〜3カ月

導入前の状況:何が困っていたか

JR九州では2023年5月に生成AIのガイドラインを策定し、その後、各部署がそれぞれ生成AIサービスを使う段階になってから、セキュリティとガバナンスの観点で導入窓口を一本化しました。2025年9月には「Google Workspace with Gemini」のPoCを開始し、各部署から約30名が参加。その後、約400アカウントで実運用に移行しています。

一方で、現場から上がる業務改善の要望をIT部門だけでは受けきれず、外部ベンダーに委託すれば費用と時間がかかる——キーマンズネットは、同社の課題をこう整理しています。運輸部でも、蓄積された車両データが十分に活用されておらず、勤務シフトの作成は夜勤や休日当番など考慮すべき条件が多い業務でした。

フィノジェン現場から
「IT部門を通さないといけない」という前提が、現場の業務改善のスピードを制限していることがあります。ツールを渡されても「自分で使っていいのか」が曖昧なままでは、現場は動きにくくなります。JR九州のケースは、ガイドラインがあり、会社としてGeminiを使える環境が用意されていたことで、現場が動ける状態が作られていた点が重要です。


導入のプロセス:実際に何をしたか

① 現場の2つの業務を、アプリの形に置き換える

対象にしたのは、運輸部が日常的に向き合う2つの業務です。1つは営業運転中の車両データをリアルタイムで分析・可視化すること、もう1つは夜勤や休日当番、スキルなどの条件を考慮して勤務シフトを自動生成することでした。

② 要件を言葉で伝え、出てきたコードを検証して改良を重ねる

開発は、自然言語でGeminiに要件を伝え、出力されたコードを検証して改良を依頼する——という作業の繰り返しで進みました。コードの9割以上はGeminiが書き、アプリはPythonのWebアプリ作成ツールであるStreamlitで構築されています。担当者が担ったのは、コードを書くことよりも、要件を伝えることと、出てきたものが意図どおりかを確かめることでした。

③ 2〜3カ月で完成させ、検証の段階へ進める

2つのアプリは2〜3カ月で完成しました。Google Workspace公式ブログの導入事例では、外部ベンダーに依頼した場合は半年から1年かかる作業だったと紹介されています。車両データのアプリは、検査代替に向けた検証が進められています。

なお、今回確認できた範囲(公式の導入事例とキーマンズネットの記事)では、開発の途中で何に迷い、どう工夫したかといった細かな経緯は紹介されていません。


導入後の変化:何が変わったか

定量的な変化:
開発期間は2〜3カ月で、外部ベンダーに依頼した場合の想定(半年から1年)より短く済んだとされています。一方、2つのアプリによる業務時間の削減効果などの定量データは、今回確認できた範囲では示されていません。

現場責任者の声:
Google Workspace公式ブログの導入事例では、鉄道事業本部 運輸部企画課 DX推進プロジェクトの上城悠貴氏(主席)が、チームのアプリについて説明しています。上城氏によれば、開発したのはプログラミングの専門知識を持たない担当者で、アプリはStreamlitで構築し、コードの9割以上をGeminiが書きました。

JR九州では、定着化に向けて部署単位での全員参加型勉強会を実施しています。また、営業部ではランディングページのたたき台作成やSEO対策も内製化しており、アプリ開発だけでなくコンテンツ制作領域にも現場主導の動きが広がっています。

フィノジェン現場から
アプリが完成した後に「使い続ける仕組み」がないと、個人の取り組みで終わります。JR九州が部署単位の勉強会を設けているのは、この取り組みを属人化させないための設計として読めます。


この事例から学べること(あなたの会社への示唆)

  • JR九州は「車両データの可視化」「条件の多い勤務シフトの作成」という具体的な業務に結びつけてアプリを作っている。何を作るかは、業務単位で決めると始めやすい
  • 「コードを書けるか」よりも「課題を言語化できるか」が、AI活用で内製開発を進める上での実質的な入り口になる
  • JR九州では、ガイドラインの策定とGeminiの導入によって会社としてAIを使える環境が用意され、その中で現場の開発が行われた。運用開始後には、定着策として部署単位の勉強会を開いている。ルールと使える環境を会社が用意し、定着の工夫は展開後に重ねる順序が参考になる

社内のAI利用ルールをどう設計するかについては、社内でAI利用を禁止していたのに使われていた——パナソニック事案が示す「禁止だけでは防げない」構造と、機能する社内ルール設計の進め方もあわせてご覧ください。

また、AIツールに任せる業務範囲の設計については、「何を任せるか」が先だ——Perplexity Teammatesから学ぶAIエージェントの業務設計3ステップが参考になります。


フィノジェンの見解:現場主導のAI内製開発、自社の準備状況チェックリスト

以下の項目に〇がついた数で判断してください。

 ⬜︎ 現場に「これを自動化・可視化できたら助かる」という具体的な業務課題がある
 ⬜︎ その課題を「どのデータを、どう見せると、何の判断ができるか」まで言葉にできる
 ⬜︎ 生成AIツールを使ってよいか、社内のルール(ガイドライン)が存在する
 ⬜︎ 小さく試す範囲(1人・1業務・1カ月など)を決めて動ける環境がある
 ⬜︎ 完成後に「他の人が使い続ける仕組み」(勉強会・マニュアルなど)を考えている

〇が4つ以上:内製開発を試し始める準備が整っています。まず1つの業務課題を選び、AIと対話しながら小さなプロトタイプを作ることから始めてみてください。

〇が2〜3つ:動ける部分と整っていない部分が混在しています。ガイドラインが未整備であれば先にそこを固め、課題の言語化が曖昧であれば「何の判断ができるようになりたいか」を書き出すことが先のステップです。

〇が1つ以下:内製開発の前に、AI活用の基盤を整える段階です。まずは現場担当者が生成AIを「日常的に使ってみる」環境と許可を作ることから始めると、課題が自然と見えてきます。


よくある質問

Q. プログラミングの専門知識がない担当者でも、本当にアプリが作れますか?
JR九州の事例では、エンジニア経験のない担当者が実際にアプリを完成させています。ただし「誰でも簡単に作れる」とは言えません。課題を言葉にする力、AIとの対話を繰り返す根気、完成の基準を自分で判断する力が必要です。ツールが書くのはコードですが、何を作るかを決めるのは人間です。

Q. 中小企業でも同じことができますか?
JR九州の取り組みは大企業の事例ですが、現場担当者が課題を言語化してAIと対話するプロセス自体は規模を問いません。ただし、JR九州ではガイドラインを策定し、会社としてGeminiを使える環境を用意していました。社内にAI利用のルールがない状態では、まずそこから着手する必要があります。

Q. GeminiやStreamlit以外のツールで同じことはできますか?
可能性はあります。Gemini以外の生成AIでもコードの生成はできますが、使えるツールは会社のAI利用ルールによって異なります。まず社内で利用が認められているツールを確認し、その範囲で試すのが現実的です。ツールの選択より、「課題の言語化」と「小さく試す」設計が先です。


行動プラン

今週中にできること(コストゼロ・1時間以内)
- 自分の業務の中で「毎回手作業でやっていること」を3つ書き出してみる
- そのうち1つについて「どのデータを、どう見せると、何の判断が楽になるか」を1段落で文章にしてみる

今月中にできること
- 社内のAI利用ルールの範囲で、書き出した課題をAIツールに伝え、「こういうアプリを作るとしたら、どんな手順で進めればいいか」を聞いてみる。実際に作り始める前に、AIとの対話で「作れそうかどうか」を確認する段階を設ける。

3カ月後の理想像
業務上の特定の判断や作業を補助する小さなアプリが1つ動いており、それを作ったプロセスが社内で共有されている状態です。完成品の完成度よりも「現場が主体で作れた」という経験が、次の取り組みへの土台になります。


参考文献

  1. JR九州の非IT部門がGeminiでPythonアプリを内製開発 2〜3カ月で完成させた方法 - キーマンズネット(ITmedia)
    https://kn.itmedia.co.jp/kn/article/2611/13/2000003142/
    └ 今回の事例の全体像と、現場の要望をIT部門だけでは受けきれないという課題背景を確認するために参照

  2. JR九州、生成AIで非エンジニアが車両データ可視化アプリを内製、開発期間は2〜3カ月 - IT Leaders(インプレス)
    https://it.impress.co.jp/articles/-/29966
    └ 「コードの9割以上をGeminiが生成」という数値、PoC参加人数・アカウント数などの具体的数値を確認するために参照

  3. JR九州、Google Workspace with Geminiを導入 非エンジニアが業務アプリを内製 - EnterpriseZine
    https://enterprisezine.jp/news/detail/25416
    └ グーグル・クラウド・ジャパンがJR九州の導入事例を公開し、非エンジニアによるアプリ開発やWebマーケティング業務の内製化に取り組んでいることを報じた記事として参照

  4. JR九州: Google Workspace with Gemini を導入し、業務の内製化とサービス品質の底上げを目指す - Google Workspace ブログ(Google Cloud Japan)
    https://workspace.google.com/blog/ja/customer-stories/jr-kyushu-implements-google-workspace-with-gemini
    └ 同社の導入事例(一次情報)。上城氏(現場責任者)の発言、2つのアプリの背景、外部ベンダーに依頼した場合の想定期間を確認するために参照

  5. 会社概要 - JR九州(九州旅客鉄道株式会社)
    https://www.jrkyushu.co.jp/company/info/outline/
    └ 社員数(7,738名、2026年4月1日現在)を確認するために参照


著者より

この事例で注目したいのは、「AIがコードを書いた」という結果よりも、「現場の担当者が課題を言葉にして、AIと対話しながら前に進んだ」というプロセスです。ツールの性能よりも、課題を言葉にできるかどうかが、取り組みを前に進められるかを左右すると考えています。まずは「作る」より「言葉にする」から始めてみてください。

株式会社フィノジェン 代表 角 浩太

Contact

AI活用の論点を、30分で整理します

具体的なテーマが未定でも問題ありません。現状業務、社内体制、進め方の不安を伺い、最初に確認すべきことを整理します。

AI活用について相談する