画面も通知も動いたのに、まだ足りない。ノーコード・ローコード・独自開発の選び方

たとえば、備品申請の画面が動き、上長へ通知も届く。「これならノーコードかAIで十分では」と思ったところで、上長の不在中に誰が承認するのか、取消済みの申請が購買台帳へ送られたらどう戻すのかが決まっていない。画面の出来に加えて、こうした業務の条件まで確かめてから、使い続ける方式を選びます。

ノーコードやAIで実装の一部を置き換えても、業務ルール、閲覧・操作の許可、連携、保守を決める仕事は残ります。候補の画面を作る前に、例外への対応、費用の増え方、データの持ち出しを同じ条件にそろえます。申請ポータルの利用範囲を広げる例を使い、比較と試作の進め方を見ていきます。

AI支援は、ノーコードにも独自開発にも使える

ノーコードは画面部品や設定を中心に作る方法、ローコードは標準機能に式やコードを加える方法、独自開発は業務に合わせてアプリのコードを設計・実装する方法です。区分は製品や作り方で変わり、独自開発にも共通部品やクラウドを使えます。

どの方法にもAI支援を組み合わせられます。利用できる機能や範囲は製品・契約によるため、作る手段とAI支援の有無を別々に調べます。

MicrosoftのPower Appsには、Copilotでアプリ用のデータテーブルを生成して確認する手順があります。利用には地域やDataverseへのアクセス、環境内の権限などの前提があります。GitHubのCopilot Agentsも、コードの作成や確認を支援します。こうした機能の存在だけで、方式ごとの速さや品質の順位までは決まりません。

開発中にAIを使うことと、完成したシステムにAIの業務判断を組み込むことも別です。承認期限や閲覧許可を決まったルールで処理できるなら、そのルールを実装できます。AnthropicのBuilding effective agentsでは、単純な構成から始める考え方と、事前に決めた手順とAIが進め方を選ぶエージェントの違いを確認できます。業務にAIがそもそも必要かは、通常のシステム化や手順改善と比べる判断表で先に確かめられます。

画面が動いた後に残る仕事

用意された画面部品やデータ構造を使い、AIにたたき台を作らせれば、その部分を一から作る作業は減らせます。案件全体の作業量は、業務の条件や利用開始後の対応も含めて見積ります。試作で確認した範囲を、画面・データ・連携・権限に分けて残します。

画面では、入力して一覧に出せるかに加え、差戻し後にどこから再開するかを見ます。データでは申請の識別番号、変更履歴、添付との対応を決めます。連携では送信成功に加えて、相手側の登録結果が分からないときに照合できるかも確認します。

権限の設計では、管理者と一般利用者の区分に加え、部門、申請1件、項目、操作ごとに許可を決めます。ボタンを隠すだけで済ませず、別の経路でも許可されていない情報を取得できないか試します。OWASPのAuthorization Cheat Sheetが勧めるのも、リクエストごとの権限確認と、適切な場所での制御です。別部門のアカウントで、APIや出力、添付も含めて確認します。

AIが生成したコードの点検も残ります。GitHub Copilot Agentsの公式資料は、生成結果をレビューしてテストするよう案内しています。生成された設定やコードを誰が確認し、問題があれば誰が直すかまでを依頼範囲に含めます。

1部門から3部門、取引先へ広げると何が変わるか

備品申請から購買情報を扱う小規模ポータルを広げる例を考えます（想定例）。人数・件数は比較に使う試験条件です。候補ごとの性能、費用、対応可否は、これから確かめます。保存件数には移行分を含みます。人数だけで方式を決めず、それぞれの条件を候補の製品や実装で満たせるか確かめます。

表1　利用範囲が広がったときに確かめる条件（想定例）

段階1で、取消と本人だけの閲覧を標準設定で満たせるなら、設定中心の案を先に試せます。段階2では代理承認と部門別の閲覧が焦点です。標準機能で実現できれば継続し、購買台帳への連携だけが足りないなら、その部分だけ追加する案を比べます。kintoneを使っている場合の判断は、kintoneの標準機能で足りるかの見方で具体的に扱っています。

同じ100人が使う段階2でも、標準設定で部門別の閲覧と代理承認を満たせる候補なら継続できます。一方、内部単価を権限のない人が取得できてしまう候補は、そのまま採用できません。安全に補える拡張方法があればローコード、補えない場合は基盤の変更や独自開発を検討します。

連携は「APIがある」で合格にせず、同じ申請を再送したときの振る舞いを決めます。AWSのMaking retries safe with idempotent APIsには、要求を識別するIDを使って重複を扱う設計例があります。このポータルの試作では、申請IDと版番号を照合単位にし、結果不明なら確認待ちにする案を試します。連携先のAPIがその方法に対応するかは、個別の仕様で確認します。

段階3では、会社別の情報分離、同時更新、取消の伝播、監査履歴を同じ試験で比べます。独自開発にも、これらを正しく実装する仕事があります。製品の公開上限は公式仕様で、応答時間や停止後の再開は対象環境の試験で確かめます。

使い続ける費用と、乗り換え・引き継ぎの条件

データを取り出した後、別の環境で何を動かせるか

BubbleのApplication and data ownershipでは、CSV等でデータを取り出せることと、アプリをコードとして出力して別基盤で動かすことを区別しています。Bubbleから離れる場合は、処理の再構築が必要です。これはBubble固有の条件なので、ほかの製品はそれぞれの公式仕様を確認します。

調べるのは、データ本体、IDと項目定義、添付、履歴、設定、追加コード、再構築手順です。ソースコードを受け取る場合も、利用する権利、動かす環境、依存部品、接続に必要な設定まで確かめます。独自開発にも、クラウドや外部APIへの依存は残ります。

人数だけでなく、課金の単位もそろえる

利用者数、実行回数、保存量、接続機能など、見積りに使う単位を候補ごとに調べます。BubbleのPricing and plansでは、処理に使う資源をworkload unitsで数える仕組みを確認できます。同じ人数でも処理内容で利用量が変わるため、通常月と利用集中時の両方で見積りを取ります。

上限を超えたときの追加請求や処理停止も調べます。設定中心の案が予算内なら継続が候補です。追加利用者や連携の費用で予算を超えるなら、処理の見直し・別プラン・別方式を再比較します。独自開発の方が安いかも、同じ利用期間と条件で比べてから判断します。

短期イベントの単純な受付フォームなら、別基盤へ移す準備より導入速度を優先できる場合があります。終了時に必要なデータを受け取れ、保存・削除の扱いが決まることを条件に、利用期間に合う準備を選びます。

担当交代では、個人アカウントを止めても動くか、誰が管理権限と接続設定を引き継ぐかを決めます。契約・費用・既製品の調達を含む比較は、SaaS・パッケージ・独自開発｜3年・5年の費用比較で整理できます。

最初の試作では、方式を変える原因になりそうな条件を試す

上長の代理として承認できた人が、代理期間の終了後も同じ申請を承認できてしまったら、一覧画面がきれいにできていても業務に使えません。そこで試作では、期間内に承認できることと、期間後には拒否されることを続けて試します。採用できるかを分ける条件を先に確かめれば、後から方式ごと作り直す判断を早められます。

最初の試作では、採用を左右する制約を選びます。段階2なら、代理承認、部門別の権限、再送時の重複防止、持ち出し後の復元です。次の表は、試す前に合格条件を書いておくための見本です。

表2　段階2で先に試す条件の記入例

試す対象	合格条件として先に書く内容	結果
例外処理	代理期間内だけ承認でき、期間終了後は拒否される。実行者を履歴で追える	未測定
閲覧・操作の許可	権限外の部門・内部単価を、画面・API・出力・添付から取得できない	未測定
外部連携	同じ申請ID・版番号を再送しても台帳の登録は1件。結果不明は照合待ちにできる	未測定
持ち出し	ID・添付・履歴の対応を別環境で復元できる。追加コードは手順付きで再構築できる	未測定

開発方式の比較・判断票と試作仕様（Excel）には、AI支援の組合せ、利用範囲の比較、試験条件に加え、判断票と試作仕様の記入済み見本・空欄版があります。候補の製品名・プラン・版・地域、公式仕様の確認日とURL、対応方法、残る不明点、確認担当を記入します。

対応方法は標準機能・設定・追加開発・手作業・対象外に分け、未確認の欄は不明のまま残します。仕様は提供元の資料や窓口、接続条件は連携先、費用は同じ前提の見積りで確認し、性能と復元は対象環境の試験で確かめます。

ノーコードを内製し、難しい連携やテストだけを外部に依頼する選び方もあります。AIで独自開発する場合も、保守担当が必要です。要件整理・設定・拡張・検証・運用のどこを誰が担うかまで決めれば、依頼する仕事も具体的になります。

本番化・再検証・中止の決め方は、試作・PoC・MVPから本番へ進む条件と見送る条件へ。依頼範囲を相談したい段階では、状況に近い業務課題を選べます。

Microsoftの環境を使っているなら、利用者と端末からPower Appsの適用条件を確かめられます（Power Apps導入前の確認｜連携・費用・運用）。

まず自社の申請で例外になる場面を一つ選び、今の道具で処理できるかを試してみてください。

業務課題から探す

参考出典

• Anthropic「Building effective agents」
• Microsoft「Build apps through conversation with Copilot」
• GitHub「Application card: GitHub Copilot Agents」
• Bubble「Application and data ownership」
• Bubble「Pricing and plans」
• OWASP「Authorization Cheat Sheet」
• AWS「Making retries safe with idempotent APIs」