AI編集プロジェクト
Lovableなど、お客様が編集する環境と権限、操作の手順。利用するサービスで何ができるかを、案件ごとに確認します。
buildsfor · 日本橋AIラボ（NAL）の開発サービス
つくった後も、自分たちで育てられる業務ソフトを。
今使っている書類やExcel、改善したい作業を見せてください。NALがAIを活用して業務に合うソフトをつくり、合意した日常の変更を自分たちで行えるように引き継ぎます。
まずは相談から。開発範囲・納品方法・費用は、着手前に合意します。
完成後の使い方に合わせて、納品方法を。
AI編集プロジェクト、GitHub、ZIPは組み合わせて納品できます。誰が保守し、どこで動かすかに合わせて、NALが提案します。
GitHubリポジトリ
ソースコードと変更履歴、構築・変更の手順。社内の開発担当者や、次の開発会社への引き継ぎにも使えます。
ZIPファイル
合意した納品版のファイルと資料を保存・受け渡しできます。変更履歴全体や、アプリを動かす環境は別に用意します。
稼働環境、外部サービス、継続保守は別途合意します。Dockerや社内サーバーなどへの納品は、案件ごとに条件を確認します。
自分たちで変更する範囲を、明確に。
日常の変更は、範囲を決めて引き継ぎ実習まで行います。専門的な対応が必要な変更には、必要に応じて支援を利用できます。
担当者が練習する日常の変更
画面の説明文や、対応する出力項目・設定の調整など。アプリに合わせて範囲を決め、サンプルと確認手順を用意します。
専門家の支援を使う変更
ログイン・権限、データベースの変更、複雑な外部連携など。専門的な確認や実装が必要な範囲を、引き継ぎ時に説明します。
本開発を始める前に、一緒に決めること
- 変更する担当者と、使う編集ツール
- 渡すプロジェクト・ソース・資料
- 稼働環境と、必要な外部サービス
- アカウントの所有者と管理の担当
- 開発費・運用費・保守の範囲
- 機能の確認方法と、引き継ぎ実習
相談の時点では未定でも構いません。NALが一緒に整理します。
操作を試す
注文データを確認し、自分の形式でCSVにする。
架空の注文を使って、欠けた項目の修正、金額の確認、CSVの列名・並び替えを試せます。
固定の架空データを使う操作例です。書類のアップロードやOCR読取は行いません。編集内容はこのタブ内だけに残り、移動・再読込で消えます。
架空の注文原本
| 注文番号 | 注文日 | 顧客名 | 商品名 | 数量 | 単価 | 金額 |
|---|---|---|---|---|---|---|
| DEMO-001 | 2026-09-01 | Sample Office A | Notebook | 2 | 1000 | 2000 |
| DEMO-002 | 2026-09-02 | Sample Office B | Paper set | 3 | 1200 | 3600 |
確認・修正する
金額は日本円の整数で入力します。 値を変更すると、この注文の確認は解除されます。
CSVの列名・順番を変更する
列名や順番を変えてみてください。注文データの内容は変わりません。
CSVプレビュー
| 注文番号 | 注文日 | 顧客名 | 商品名 | 数量 | 単価 | 金額 |
|---|---|---|---|---|---|---|
| DEMO-001 | 2026-09-01 | Sample Office A | Notebook | 2 | 1000 | 2000 |
| DEMO-002 | 2026-09-02 | Sample Office B | Paper set | 3 | 1200 | 3600 |
表計算の数式として扱われる先頭文字は、文字列として出力します。
強調された項目を修正し、2件とも内容を確認するとダウンロードできます。
開発・納品の進め方を詳しく見る
AIエージェントが、FDEになる。
一つの顧客課題を、より強い標準Buildへ変える。
buildsforはAIエージェントをForward Deploymentの循環へ適用します。仕事を理解し、製品適合を確認し、承認された標準製品の変更を実装・検証・導入支援し、再利用可能な学びを共通製品へ戻します。
- 現在の状態
- 公開運用モデル・AI実行経路は未接続
- ワークフローrevision
- buildsfor-forward-deployment-workflow-v1
一つの累積的な循環
限定された困りごとから、再利用可能な後継Buildへ
各段階で確認可能な記録を作ります。顧客の依頼が、そのまま実装、提供可能性、または保守し続ける個別forkへ変わることはありません。
- 01
困りごとの境界を決める
実現したい成果、現在の業務、利用者、情報分類、連携境界、配置条件、成功指標を整理します。
Problem Brief
- 02
適合または不適合を判断する
正確な標準製品product-truth revisionと比較します。不明な境界は肯定的な主張に変えず、確認事項として残します。
適合判断とreason codes
- 03
導入計画を固定する
正確な製品revision、許可された設定または共通変更、データ境界、検証方法、責任分担、停止条件を明示します。
versioned deployment plan
- 04
AIエージェントが実装する
固定された計画内で、承認済みの設定、共通本体改善、または別に製品化する拡張をAIエージェントが作成します。
追跡可能な変更set
- 05
正確な変更を検証する
限定されたテストを実行し、確認内容、観測結果、主張の対象外を分けたEvidenceを作成します。
検証結果と限定されたEvidence
- 06
Owner gateを通じて導入する
顧客アクセス、機密データ、本番変更、例外、最終受入の権限はNihonbashi AI Labが保持します。
Owner判断と受入
- 07
学びを共通製品へ戻す
再利用可能な改善を、共通の後継BuildVersionまたは別revisionの拡張とし、将来の適合判断へ利用します。
共通製品revision
実行と説明責任
技術作業はAIエージェント。権限と説明責任はNAL。
目標は、永続的な人手の受託開発でも、監督のない顧客向けコーディングAIでもありません。自動化する作業と、責任を伴う判断を分けます。
AIエージェント
承認された境界内で、反復可能な技術作業を準備・実行します。
- Problem Briefを構造化し、正確なproduct truthと比較する
- 導入計画、設定、共通変更、または拡張を準備する
- 実装、テスト、文書化、限定されたEvidence作成を行う
- 導入手順と再利用可能な後継製品変更を準備する
Keijiro / Nihonbashi AI Lab
顧客、製品、データ、本番に関する判断の説明責任を保持します。
- 製品優先度、価格、契約、権利、顧客への約束を決める
- 機密データ、credential、顧客アクセスを承認する
- 本番操作、例外、incident対応を承認する
- 受入境界と再利用可能な変更の最終処理を決める
標準製品としての規律
すべての依頼を、四つの製品結果のどれかへ分類する。
buildsforは顧客ごとに別の保守forkを残しません。要求は管理された製品結果の一つに適合する必要があります。
設定または導入作業
保守する製品系統を変えず、既存の標準製品を利用します。
共通本体の改善
一つの共通製品系統を通じて、今回と将来の顧客のために標準製品を改善します。
製品化したconnectorまたはextension
保守可能な製品資産になる場合だけ、別revisionを持つ再利用可能なcomponentとして作成します。
依頼を断る
標準、権限、再利用境界を満たせない要求を、無理に製品へ当てはめません。
fail-closed境界
このワークフローが主張しないこと
保守し続ける顧客固有forkは作らない
顧客固有コードを、暗黙に第二の非公開製品系統へ変えません。
本番権限は自動発生しない
AI出力だけで、契約、release、Entitlement、導入、受入、本番変更は成立しません。
このページでは顧客データを受け取らない
案件説明、文書、連絡先、credential、機密情報を収集しません。
接続済みAI delivery runtimeはまだない
公開ワークフローはversionedな実体ですが、Gemini、Codex、その他の実行providerはこのページに接続されていません。