AI アプリ開発とは、要件から本番へ出すまでの工程を AI に任せてアプリを作ることです。

  • 工程（要件・設計・実装・試験・本番へ出す）ごとに AI の席を分けて任せる形
  • 当社が AI の席で作ったアプリで実際につまずいた所と、直した決まり
  • 個人やコードを書かない人が、AI に作らせるときに自分で持つべき所

当社は開発を AI の席で回している

当社のアプリ開発は AI の席で回しています。2026-10-21 の 1 日では、本番へ 33 回出しました（社の実測 2026-10-21）。席とは、ある仕事を受け持つ AI の持ち場のことです。1 体の AI に全部を頼むのではなく、工程ごとに受け持ちを分けています。

この頁は、その形で作ったアプリで実際に起きた事の記録です。AI にアプリを作らせる手順そのものは AI エージェントの作り方 に、複数の席を同時に動かす形は マルチエージェント の頁にまとめています。

工程ごとに席を分けて任せる

ai アプリ開発を工程に分けると、それぞれの席が「何を終えたら次へ渡すか」を決めやすくなります。当社で起きた事を、どの工程の席の話かで並べると次のようになります。

工程席が受け持つ事当社で起きた事
要件「何ができたら終わりか」を決める根拠の無い終わりの定義（間を空けずに 22 往復）が一人歩きした
設計外の仕組みの上限に収まる作りにする1 往復の呼び出しを 12 本から 3 本に束ねた
実装・試験作って、実際に近い形で試す知らせ先を 1 本止めて見張りを試し、「見当たらない」として出ると分かった
本番へ出す置き場へ送り、本番に載せる門は合格なのに、送り出しが番号 141 で終わり置き場に載っていなかった（3 回）
本番の後本番の様子を見張る読み上げが 7 日で 200 が 1 回・502 が 6 回。原因は外部サービスの残高切れ

出典: 社の実測 2026-09-20（終わりの定義・呼び出しを束ねた記録）、社の実測 2026-10-15（送り出しの記録）、社の実測 2026-10-21（見張りの試験・本番の読み上げの記録）

受託開発を回すための製品の使い方は アプリ開発の使いどころ にあります。この頁は、自分のアプリを AI の席に作らせるときの記録です。

要件と設計: 終わりの定義に根拠を持たせる

外の仕組みの上限に当たって落ちた

当社が AI の席で作った、声で話すアプリは、音声合成の外部サービスの毎分の呼び出しの上限に当たって落ちました。上限は実測で毎分 12〜13 回でした（社の実測 2026-09-20）。

設計の席は、1 往復（利用者が話して、アプリが答える 1 回）で使う呼び出しを 12 本から 3 本に束ねました。これで、利用者の普通の通話では落ちなくなりました（社の実測 2026-09-20）。

落ちていたのは、人の使い方ではない試験だった

束ねた後も残っていたのは、「間を空けずに 22 往復」という試験での失敗でした。人はそんな話し方をしません。根拠の無い終わりの定義が、いつの間にか「これが通れば終わり」として一人歩きしていました（社の実測 2026-09-20）。

当社は終わりの定義を「実際の通話で分あたり何往復になるかを測り、その値で落ちないこと」に直しました（社の実測 2026-09-20）。AI の席は、渡された終わりの定義に向かってまっすぐ働きます。だから要件の席には、数字の出どころまで書かせます。

本番へ出す: 「着いた」は置き場を読み直して確かめる

当社では、本番へ送る前に試験が走る門（送り出しの前に走る試験）を置いています。この試験が長くかかった回に、門は合格なのに、送り出し（git push）が終わりの番号 141 で終わり、置き場に載っていませんでした。同じ席で 3 回起きました（社の実測 2026-10-15）。

送り方を HTTPS に替えて着地させました。そのうえで、門の合格や終わりの番号を「着いた」の証拠にしない決まりにしました。送り出しの後は、置き場を読み直して（ls-remote）、送った物が本当に載っているかを測ります（社の実測 2026-10-15）。

1 日に何十回も本番へ出す形では、「送った」と「着いた」を取り違えると、載っていない物の上に次の仕事が積まれていきます。席には、手元の合図ではなく、行き先を読み直した結果で報告させます。

試験と本番の後: 見張りは止めてみて確かめる

止めた物は「見当たらない」として出る

決済の知らせが止まったら知らせる見張りを作り、試しに知らせ先を 1 本止めて試験しました。すると、決済サービスの一覧は止めた知らせ先を返しませんでした。つまり本物の停止は、「止まっている」ではなく「見当たらない」として出ると分かりました（社の実測 2026-10-21）。

また、記録の一致で鳴らす警報は、作ってから効くまで数分かかりました。1 回目の試験では鳴りませんでした（社の実測 2026-10-21）。見張りは、作っただけでは効いているか分かりません。実際に止めてみて、鳴るところまで見て初めて「できた」と言えます。

失敗を見たら、まず前の版でも起きていたかを見る

本番の読み上げを 7 日分見ると、200（成功）が 1 回・502（失敗）が 6 回でした。調べると前の版から起きており、直しによる回帰ではありませんでした。原因は外部サービスの残高切れでした（社の実測 2026-10-21）。

失敗が続くと、直前の直しを疑いたくなります。先に「前の版でも起きていたか」を確かめると、直す所（アプリのコードか、外の契約や残高か）を取り違えずに済みます。

個人やコードを書かない人が持つべき所

ai アプリ開発を個人で始めるときも、ノーコードで AI に作らせたいときも、コードを書くのは席に任せられます。それでも、当社の記録から見て人の側に残る仕事は次の 3 つです。

人が持つ所当社で起きた事
終わりの定義の根拠根拠の無い「22 往復」の試験が一人歩きした
「着いた」の確かめ方門の合格と番号 141 を見ても、置き場には載っていなかった（3 回）
本番の見張りが効いているかの試し警報の 1 回目は鳴らず、効くまで数分かかった

出典: 社の実測 2026-09-20、社の実測 2026-10-15、社の実測 2026-10-21

コードを書かずに作る道は AI エージェントの作り方 に、席に仕事を任せる考え方の全体は AIエージェント の頁にまとめています。

よくある質問

AI アプリ開発では、どこまで AI に任せられますか？

当社では、要件・設計・実装・試験・本番へ出す、の工程ごとに AI の席を分けて任せており、2026-10-21 の 1 日で本番へ 33 回出しました（社の実測 2026-10-21）。人は、終わりの定義の根拠と、着いたか・効いているかの確かめ方を持ちます。

個人で AI アプリ開発をするとき、何に気をつければよいですか？

終わりの定義に根拠を持たせることです。当社では「間を空けずに 22 往復」という人の使い方ではない試験が一人歩きしたので、「実際の通話で分あたり何往復になるかを測り、その値で落ちないこと」に直しました（社の実測 2026-09-20）。

AI が「本番へ出した」と言ったら、出たと考えてよいですか？

置き場を読み直して確かめます。当社では、門が合格でも送り出しが終わりの番号 141 で終わり、置き場に載っていなかったことが同じ席で 3 回ありました（社の実測 2026-10-15）。以後、置き場を読み直して（ls-remote）着いたかを測っています。

ノーコードで作ったアプリが本番で失敗したら、まず何を見ますか？

前の版でも同じ失敗が起きていたかを見ます。当社の読み上げは 7 日で 200 が 1 回・502 が 6 回でしたが、前の版から起きており、原因は外部サービスの残高切れでした（社の実測 2026-10-21）。

出典

  • 社の実測 2026-09-20（音声合成の外部サービスの毎分の上限 12〜13 回、呼び出しを 12 本から 3 本に束ねた記録、終わりの定義の直し）
  • 社の実測 2026-10-15（送り出しが終わりの番号 141 で終わり置き場に載っていなかった 3 回、HTTPS での着地、置き場を読み直す決まり）
  • 社の実測 2026-10-21（決済の知らせの見張りの試験、警報が効くまでの数分）
  • 社の実測 2026-10-21（本番の読み上げ 7 日分の 200 と 502、残高切れの記録）
  • 社の実測 2026-10-21（1 日で本番へ 33 回出した記録）

申し込みと入れ方は 始め方 の頁にあります。