Codexで業務アプリは作れる？実際に開発して分かった設計と運用のポイント

結論として、Codexを使えば、実際の業務データを保存できる業務アプリまで作れます。

近年、「AIに指示するだけでアプリができた！」という話題をよく目にします。

しかし、いざ自社の業務で使おうとすると、「データの保存先はどうする？」「社内共有の権限設定は？」「半年後の改修は誰がやる？」といった、実運用に向けた壁にぶつかりませんか？

今回、Codexを使って、Googleスプレッドシートと同期する実用的な「プロジェクト管理アプリ」を開発しました。そこで分かったのは、会社で使えるアプリにするための鍵は「長いプロンプトを書くこと」ではない、ということです。

本記事では、AIが作る「いい感じのモック」を「現場で使える業務アプリ」へと昇華させるための、最も重要な「設計の考え方」について解説します。

YouTube動画はこちらから https://www.youtube.com/watch?v=I7Zs_BRItl4

Codexで業務アプリは本当に作れるのか？

Codexで業務アプリを作ることは可能です。

今回試した範囲では、画面だけのモックではなく、データの保存・同期、共有、アクセス制御を含むプロジェクト管理アプリまで作れました。

当社ではこれまで、Google AppSheetを使って企業向けの在庫管理、申請ワークフロー、顧客管理、日報、案件管理などを開発してきました。

その経験を踏まえて今回取り組んだのが、Codexを使った業務アプリ開発です。

AIコーディングツールの進化によって、これまでノーコードでは難しかった細かな画面や独自処理も、現実的な開発対象になりました。

ただし、「作れる」という言葉を、短い指示だけで実運用まで自動的に完成するという意味で捉えるべきではありません。

Codexで業務アプリを開発できることと、業務アプリ開発そのものが簡単になったことは同義ではありません。

Codexでどんなプロジェクト管理アプリを作ったのか？

今回作ったのは、Google Workspace環境での利用を想定したガント型のプロジェクト管理アプリです。

タスクを管理する画面だけでなく、裏側のスプレッドシートと同期し、変更内容を業務データとして保存できるところまで実装しました。

ガントチャートとタスク管理を実装

アプリにはガントチャートがあり、タスクの追加や編集、ステータス変更、担当者管理ができます。

こうした画面表現や独自処理は、ノーコードツールの標準部品だけでは実現しにくい領域です。

AI開発によって、業務に合わせた画面を一から実装する選択肢が取りやすくなりました。

スプレッドシートと同期し、業務データとして保存

今回のアプリでは、データの保存先にGoogleスプレッドシートを使いました。

画面上で担当者の案件を「進行中」から「完了」へ変更し、同期すると、スプレッドシート側のステータスも「完了」に変わります。

つまり、ブラウザ上で見た目だけが動くモックではありません。

アプリ上の操作が保存先へ反映され、業務データとして残る構成です。

業務アプリでは、画面が動くことに加えて、操作結果が正しいデータとして保存・管理されることが必要です。

社内共有とアクセス制御も考慮

このデモアプリは社内で共有でき、Googleの認証と公開範囲を利用したアクセス制御も組み込んでいます。

今回採用した技術構成は、データがGoogleスプレッドシート、バックエンドと画面処理がGoogle Apps Scriptです。

これはGoogle Workspaceを利用する社内向けアプリを想定した今回の選択であり、AI開発だから必ずこの構成になるわけではありません。

「動くアプリ」と「業務で使えるアプリ」は何が違うのか？

「動くアプリ」と「業務で使えるアプリ」の違いは、実際の仕事に適合し、継続的に運用できるかどうかです。

画面上で期待した動きをした時点を完成とすると、業務利用に必要な条件を見落とします。

業務アプリに必要だと考えているのは、少なくとも次の5点です。

• 実際の業務に合っている
• データが正しく保存・管理される
• セキュリティが考慮されている
• 安定して運用できる
• 後からメンテナンス・改善できる

今回のアプリはデモですが、この考え方を前提に作りました。

特に、業務アプリは公開したら終わりではありません。

運用を始めれば、画面の変更や機能追加が必要になります。そのため、半年後に当時の前提を理解し、改修できる状態まで含めて設計する必要があります。

AI開発では、アプリを一度動かすことより、半年後にも安全に改修できる状態を作ることが業務利用では重要です。

AIに「ガントチャートを作って」と頼むだけではなぜ足りないのか？

AIは短い指示から、それらしいアプリを作れます。

しかし、自分たちの業務に合うアプリへ近づけるには、仕様、UI、判断、確認、修正を積み重ねなければなりません。

今回Codexを使って最も強く感じたのが、この違いでした。

一回目の出力で「いい感じ」のものはできます。

しかし、「ガントチャートを作って」という一言だけで、業務に必要な機能、データ構造、アクセス制御、運用方法まで備えたアプリになるわけではありません。

これは、AIが役に立たないという話ではありません。

実装の速度や、以前は難しかったUIを形にする力は大きく向上しています。

そのうえで、人間側には、何を作るのかを決め、出力を確認し、次の判断を積み重ねる役割が残ります。

AIは「いい感じのアプリ」を素早く作れますが、「自分たちが欲しい業務アプリ」は工程の積み重ねによって作られます。

AIとの会話だけで開発すると何が起こるのか？

AIとのチャットだけで変更を重ねると、決定事項、現在地、残作業、変更理由が会話の中に埋もれます。

人間だけでなく、AI側もプロジェクトの全体像を見失いやすくなります。

最初は会話だけでも進められます。

しかし、変更が増えるにつれて、「何が正式な仕様なのか」「何が終わっているのか」「なぜこの形にしたのか」が分かりにくくなります。

別のセッションで再開するたびに説明し直すことになれば、認識のずれも起こりやすくなります。

さらに問題になるのが、しばらく時間が経ってからの改修です。当時の判断がチャットにしかなければ、長い会話を読み返さなければなりません。担当者が変わった場合は、さらに引き継ぎが難しくなります。

AIとの会話は作業を進める場所にはなりますが、プロジェクトの正式な記憶を長期的に管理する場所には向きません。

AI開発ではなぜ「プロジェクトの記憶」が必要なのか？

AI開発でプロジェクトの記憶が必要なのは、AIと人間が現在地を共有し、同じ前提から作業を再開できるようにするためです。

今回の開発では、会話とは別に、何を作るか、今どこにいるか、何が残っているか、なぜその判断をしたかをプロジェクト側へ残しました。

これらをSPEC、STATUS、TASKS、DEVLOGという4つの管理要素とします。

ただし、重要なのはファイル名ではありません。

仕様・現在地・残タスク・判断理由が、特定のチャットに依存せず確認できる状態になっていることです。

数日後でも同じ現在地から再開できる

作業を途中で止めても、現在地が記録されていれば、数日後にCodexを開いたときに続きから始められます。

以前の会話をたどり、状況を一から説明し直す必要が減ります。

他の人や他のAIへ引き継げる

プロジェクトの前提が外部化されていれば、開発者本人だけでなく、別の担当者や別のAIも内容を確認できます。

特定の人と特定のチャットだけが事情を知っている状態を避けられます。

半年後の改修で判断の前提を確認できる

業務アプリでは、公開後に変更や機能追加が発生します。

判断理由まで残っていれば、半年後に改修するときも、既存仕様の背景を理解したうえで変更できます。

Codexへの指示を短くできるのは、プロンプトの工夫だけでなく、Codexが参照できるプロジェクトの記憶が整っているからです。

Codexに実際の改修作業を任せるとどう進むのか？

プロジェクトの記憶が整っていれば、「残っているタスクを教えて」「このタスクを実行して」といった短い依頼からでも、Codexは現在地を踏まえて作業できます。

短文だけで魔法のように進んだのではなく、判断に必要な情報がプロジェクト側に残っていたことがポイントです。

動画ではまず、Codexへ残タスクを尋ねました。

Codexはプロジェクト内の記録を読み、正式な残タスクは0件で、21件すべて完了していると回答。

そのうえで、まだ正式タスクになっていない改善候補として、プロジェクト複製、担当者未割り当てタスクの警告表示、詳細パネルからの簡易ステータス変更を提示しました。

今回は「担当者未割り当てタスクの警告表示」を選び、実行を依頼しました。

Codexは改善候補を正式なタスクにし、まずモックを作成。

画面を確認し、問題がないと伝えた後に、本実装とデプロイ、関連するプロジェクトファイルの更新まで進めました。公開された画面でも、未割り当ての表示が反映されていることを確認できました。

この実演が示しているのは、プロンプトが短ければよいということではありません。

短い指示でも、何をすべきか、完了時に何を更新すべきかを判断できる土台があったということです。

AIへ仕事を任せやすくするには、毎回詳しく説明するより、作業の前提と現在地をプロジェクト側から参照できるようにすることが有効です。

AIにどこまで開発を任せるべきか？

AIに任せる範囲は、用途とリスクに応じて決めればよく、すべての工程を自動化する必要はありません。

今回の実演では私が画面を確認しましたが、テスト、仕様への適合確認、画面テストまでAIに任せる選択肢もあります。

たとえば、影響の小さい表示変更ならテストまで任せやすい一方、重要な業務判断や権限に関わる変更は人間が確認した方がよい場合があります。

どこに確認工程を置くかは、アプリの用途、障害時の影響、扱うデータに応じて決めるべきです。

AI開発の目的はすべてを自動化することではなく、必要な品質を満たす業務アプリを完成させることです。

AppSheetとCodexによるAI開発はどう使い分けるべきか？

AppSheetとAI開発は、どちらか一方に置き換える関係ではありません。

標準的な業務アプリを素早く運用したい場合はAppSheetが便利で、細かなUIや高度な独自処理が必要な場合はCodexを使った開発が有力です。

AppSheetはGoogle Workspaceとの親和性が高く、スプレッドシート、Googleドライブ、Gmailなどと連携しやすいツールです。

インフラやサーバーを強く意識せず、ノーコードで開発から運用へ進められる点は、現在でも大きな利点です。

一方で、ノーコードは用意された部品を組み合わせる仕組みであるため、細かな画面デザインや、高い独自性を持つ処理には制約があります。

今回のような自由度の高いガントチャートも、その一例です。

判断基準は、ツールの新しさではなく業務要件です。標準的な管理画面やワークフローを早く作るならAppSheet、独自の画面や処理が価値を左右するならAI開発、というように選べます。

AppSheetとAI開発は競合する選択肢ではなく、業務要件に応じて使い分ける選択肢です。

業務要件によって技術構成をどう考えるか？

AI開発の技術構成は一つに固定されません。

今回はGoogleスプレッドシートとGoogle Apps Scriptを使いましたが、規模や目的が変われば別の構成を検討します。

規模が大きい場合の選択肢としてPostgreSQLやCloud SQL、大量データを分析する場合はBigQueryという選択肢もあります。

大切なのは「AIで作るからこの技術を使う」と決めるのではなく、データ量、処理内容、利用人数、運用体制などの要件から構成を選ぶことです。

AIは実装手段を広げますが、保存先やインフラは業務要件に合わせて選ぶ必要があります。

Codexで業務アプリを作るなら、完成後の運用から逆算する

Codexを使った業務アプリ開発は、すでに現実的な選択肢です。

今回も、ガントチャートのような自由度の高い画面を作り、スプレッドシートへデータを保存し、社内共有できる状態まで進められました。

一方で、AI開発はモックを作りやすいからこそ、画面が動いた時点で完成したように感じやすい面があります。

業務で使うなら、データ管理、セキュリティ、安定運用、保守・改修まで考えなければなりません。

その土台になるのが、AIとの会話の外側にプロジェクトの記憶を残すことです。

仕様、現在地、残タスク、判断理由を共有できれば、AIへの依頼、作業の再開、他者への引き継ぎ、半年後の改修がしやすくなります。

Codexで業務アプリを作るときは、最初の完成画面ではなく、運用開始後も改善を続けられる状態をゴールに置くことが重要です。

よくある質問 

Codexだけで業務アプリを完成できますか？

Codexは設計や実装、テスト、改修を広く支援できますが、人間の判断が不要になるわけではありません。

何を業務要件とするか、どこまでAIへ任せるか、どの確認を人間が行うかを決める必要があります。

特にセキュリティや業務上の影響が大きい機能は、リスクに応じた確認が必要です。

プログラミング未経験でもCodexで業務アプリを作れますか？

以前より着手しやすくなっていますが、「業務内容を整理する」「必要な仕様を決める」「出力を確認する」という役割は残ります。

コードを書けるかどうかだけでなく、完成した動作が正しいと判断できる知識や、困ったときに検証できる体制も考えておく必要があります。

AppSheetからAI開発へ移行した方がよいですか？

一律に移行する必要はありません。既存のAppSheetアプリが業務要件を満たし、安定して運用できているなら、その利点を生かせます。

細かなUIや独自処理が必要になり、AppSheetの制約が業務上の課題になったときに、AI開発を新たな選択肢として検討するのが自然です。

プロジェクトの記憶はチャット履歴では代用できませんか？

短期・小規模な試作ではチャット履歴でも進められます。しかし変更が増えたり、セッションや担当者が変わったりすると、正式な仕様と途中の案を区別しにくくなります。

継続運用する業務アプリでは、確定した情報を会話から分離して参照できる状態が役立ちます。

最初からすべての仕様を決める必要がありますか？

すべてを固定する必要はありません。開発中に確認や修正を重ねること自体は自然です。

重要なのは、変更後の正式な仕様、現在地、残作業、判断の背景が更新され、次の作業時に参照できることです。

まとめ

Codexを使えば、従来のノーコードでは難しかった画面や独自処理を持つ業務アプリまで作りやすくなりました。

今回のプロジェクト管理アプリでも、ガントチャート、タスク管理、スプレッドシートとの同期、社内共有、アクセス制御まで実装できました。

ただし、「いい感じのアプリ」がすぐに作れることと、「自分たちが欲しい業務アプリ」が完成することは別です。

業務で使うには、仕様と確認を積み重ね、データ管理、セキュリティ、運用、将来の改修まで考える必要があります。

そして、その開発を支えるのが、仕様・現在地・残タスク・判断理由をAIとの会話の外側へ残すという考え方です。

短い指示でCodexへ仕事を任せられる状態は、プロンプトのテクニックだけでなく、この土台から生まれます。

＜無料資料をプレゼント！＞AI業務アプリ設計「WHY編」

AIで業務アプリを作ってみたいものの、「いい感じ」の試作から先へ進めない。
あるいは、長期運用や半年後の改修まで考えた進め方を知りたい。

そんな方に向けて、AI業務アプリ開発でプロジェクトの記憶が必要になる理由をまとめた無料資料をご用意しています。

無料資料では、なぜ仕様・現在地・タスク・判断を会話の外側へ残す必要があるのかを、WHY編として整理しています。

具体的なファイルテンプレート、運用ルール、Codexへの指示方法、実装フローなどのHOWへ進む前に、まずは長期運用できるAI開発の土台となる考え方を確認してください。

▶︎ Codex、Claude Codeを使ったAI開発の進め方！無料資料はこちら