3 MINUTES OVERVIEW
3分でわかる、浅間AIの業務アプリ開発
浅間AIでは、いきなりコードを書き始めません。
現場の業務を理解し、何を仕組みにするべきかを整理したうえで、AIに設計・実装させ、人がレビューして本番運用へ進めます。
01
業務を聞く
現場の困りごと・手作業・例外をヒアリング
02
AIで整理する
会話を要件・業務ルール・権限へ構造化
03
最適な形を選ぶ
Web / Desktop / Hybrid
04
Claude Codeで高速実装
一旦「動く形」を短期間で作る
05
人がレビュー・テスト
業務・安全性・例外・使いやすさを確認
06
本番導入・改善
Productionへ移し、実際の運用から改善を続ける
「AIにコードを書かせること」ではなく、「正しい業務を、正しい仕組みにすること」が中心です。
なぜ今
中小企業でも、
自社専用アプリを持てる時代になった
以前
- 業務担当者
- 要件整理
- エンジニア
- 設計
- コーディング
- 数週間〜数か月
現在
業務担当者 ＋ AI ＋ Claude Code
初期モックを、短期間で動く形まで作れます。
モック＝実際に画面を動かして、方向性を検証する試作品。
「速く作れる」≠「すぐ本番運用できる」
既にあるクラウドソフトで十分な業務は、無理に自作しません。個社のルールが大きい、二重入力がある、確認と例外が多い、というときに、小さな専用アプリが向きます。
思想
開発は、コードから始めません
- 01現場の困りごと
- 02現在の業務
- 03判断ポイント
- 04例外
- 05必要データ
- 06権限
- 07仕様
- 08実装
「何を作るか」の解像度が、AIの成果物の品質を決める。
AIは、渡された情報の範囲でしか正しく動けません。曖昧な指示からは、曖昧な成果物しか生まれません。
ヒアリング
まず、現場の声を
「設計可能な情報」に変える
01
顧客との会話
現場の声を聞く
02
録音
Plaud 等で会話を残す
03
文字起こし
テキストにする
04
AIで構造化
目的・権限・例外へ分ける
05
要件定義
設計できる入力にする
Plaud は、会話を録音し、文字起こし・整理に使える録音デバイス／サービスです。特定製品の宣伝ではなく、会話を残す手段の一例です。
聞くことの例
- 今はどうやっている？
- どこが面倒？
- 何を何度も入力している？
- どこでミスが起きる？
- 誰が判断している？
- 例外は何？
- 絶対に自動化してはいけない部分は？
議事録を作ることが目的ではありません。
後続のAIが設計に使える、「構造化された入力」へ変換することが目的です。
設計項目
AIへ渡す前に、
10項目を整理する
01
目的
何のための仕組みか。終わったあとに、何が楽になっているか。
02
利用者
誰が、どの場面で使うか。経営者、現場、外部の専門家まで。
03
現在の業務
いまの手順。Excel、紙、口頭、既存ソフトのどれで回しているか。
04
必要機能
最初から全部はいらない。検証したい中核だけを先に決める。
05
データ
何を残すか。社員、顧客、履歴、ファイルの所在。
06
権限
誰が、何を見る／編集するか。後付けにしない。
07
業務ルール
付与日数、承認の順番、締め日など、決まっている計算と手順。
08
例外
休職、振替、イレギュラー。ここで漏れやすい。
09
外部連携
勤怠、会計、メール、カレンダーなど、つなぐ相手。
10
セキュリティ
個人情報、秘密情報、バックアップ、監査の記録。
誰が、何を、見る／編集するかを、後付けにしない。
TECHNOLOGY FOLLOWS THE WORK
技術から決めない。
業務から決める。
浅間AIが標準化するのは、「すべてをWebアプリにすること」ではありません。
業務を理解し、その仕事に合う形を選ぶことです。
アプリの形
Webアプリが正解とは限りません
標準化するのは、アプリの形ではなく、開発の方法です。
Web App
向くこと
- ・複数人
- ・スマホ
- ・共有
- ・権限
- ・通知
- ・リアルタイム
- ・中央のデータベース
例：給与・勤怠・CRM・予約・顧客管理
Desktop / Local
向くこと
- ・1人〜少人数
- ・PC上のファイル
- ・大量ファイル
- ・動画・画像
- ・PPTX生成
- ・オフライン
例：提案書生成、動画処理、ファイル加工
Hybrid
向くこと
- ・Web側：共有・権限・承認・知識
- ・Local側：大量処理・PPTX・動画・ローカル連携
例：共有と承認はWeb、重い生成は手元のエンジン
事例
同じ浅間上昇AIでも、
最適なアプリ形式は違う
給与・労務
複数人で共有し、権限とスマホが必要
確認・申請・通知が複数人にまたがる業務は、Web向きです。
- ・複数人
- ・スマホ
- ・権限・通知
- ・共有データベース
- ・社労士など外部アクセス
→ Web向き
提案君
AIで営業提案書を作る社内ツール
案件情報や社内Knowledgeを参照し、PowerPoint等の提案資料を生成する「制作ツール」型のアプリ。
- ・成果物の生成が中心
- ・PowerPoint
- ・PC上のファイル
- ・1人〜少人数から開始
- ・共有は初期必須ではない
→ Desktop / Local向き
「Webにしなかった」ことが問題なのではありません。実際の業務に合った形から始めます。将来、複数人利用・承認・共有が重要になれば、Web ＋ 手元の生成エンジンという Hybrid にもできます。
自社の場合、
Web・デスクトップ・既存SaaSの
どれが合うのか？
最初からアプリを作る前提でなくても構いません。現在の業務を整理し、「既存サービスで十分か」「小さな専用アプリを作るべきか」から一緒に考えます。
30分の個別相談で整理する →役割分担
AIに全部任せません
AI
曖昧さを扱う
- ・文章
- ・画像
- ・分類
- ・要約
- ・候補抽出
Program
正確さを扱う
- ・計算
- ・権限
- ・状態
- ・確定
- ・履歴
Human
責任を持つ
- ・最終判断
- ・レビュー
- ・例外
- ・責任
標準フロー
浅間上昇AIの標準開発フロー
01
業務ヒアリング
現場の困りごと、判断、例外を聞く
02
AIで構造化
会話を、設計に使える項目へ整理する
03
要件定義
何を作り、何を作らないかを言葉にする
04
アプリ形式選択
Web / Desktop / Hybrid を業務から決める
05
AI設計
構成、画面、データのつながりを先に出させる
06
人間レビュー
業務に合うか、危険はないかを人が見る
07
Git checkpoint
戻れる地点を残してから、大胆に実装する
08
Claude Code高速実装
確認済みの設計を、動く形まで一気に進める
09
モック確認
画面を動かし、方向性が合っているかを見る
10
テスト・修正
権限、例外、壊れ方まで確認する
11
Staging
本番の直前に、人が確認する環境
12
Production
利用者が使う本番。承認されたものだけ
13
運用・改善
使って分かったことを、次の修正に戻す
FOR BUSINESS OWNERS
経営者目線で言えば、
できることはシンプルです。
これまで、
- Excel
- 手入力
- 転記
- 人の記憶
で回していた自社固有の業務を、以前よりはるかに小さな開発負担で、専用の仕組みに変えられるようになりました。
重要なのは、技術の名前を覚えることではありません。
「どの業務を仕組みにするべきか」を決めることです。
高速実装
一旦「動く形」は、
AIエージェントに一気に作らせる
Claude Code は、指示に沿ってファイル作成やコマンド実行を進めるAIコーディングの仕組みです。構造化した要件を渡すと、構成・データベース・画面・API・実装まで一気に進められます。
- 構造化要件
- Claude Code
- システム構成
- DB
- 画面
- API
- 実装
CLAUDE.md とは
Claude Code が、そのプロジェクトでどう動くべきかを定める「AI社員の業務マニュアル」です。毎回チャットで言い直すのではなく、プロジェクトに埋め込みます。
- ・使用技術
- ・ディレクトリ
- ・命名
- ・テスト
- ・セキュリティ
- ・禁止事項
- ・Git運用
高速化と統制
初期モックを高速で作るときの
強力な実行方法
権限確認のプロンプトをスキップし、その実行ユーザーに許可された範囲で、ファイル操作やコマンド実行を連続して進める起動オプションです。速いことと、安全であることは別です。
01 高速化
一旦動く形を一気に作る
権限確認の待ちを減らし、Development で初期モックを連続して進める。
02 条件
壊れても戻せる隔離環境
Git checkpoint、Sandbox、Development。戻れる場所があるときに限る。
03 禁止
本番・実データ・Secrets は触らない
本番DB、実顧客データ、本番Secrets、削除すると困る領域では使わない。
claude --dangerously-skip-permissions向いている
- ・新規プロジェクト
- ・初期モック
- ・ダミーデータ
- ・Development（開発環境）
- ・Sandbox（隔離した作業場所）
避ける
- ・Production（本番）
- ・本番のデータベース
- ・実顧客データ
- ・秘密鍵・本番のSecrets
- ・削除すると困る領域
Production で、無制限にこの方法を使うことは推奨しません。
セーブポイント
Gitは、
AI開発の「セーブポイント」
Git は、変更履歴を管理し、問題があれば過去へ戻せる仕組みです。GitHub は、その履歴をクラウド上で保管・共有するサービスです。
- 正常
- Commit
- AI実装
- 問題
- Rollback
AIを大胆に動かすほど、Gitが重要になります。
環境
開発・確認・本番を分ける
Development
AIが大胆に作る場所
Staging
人が確認する、本番直前の場所
Production
利用者が使う本番。承認されたものだけ
Claude Code に、Production を直接自由に触らせない。
モックと本番
「数十分で動いた」
と「本番で使える」は別
検証と運用の違い
モック
Production
目的
方向性を検証する
業務で使い続ける
できること
動く画面と基本機能
認証・権限・例外・エラー処理
守り
ダミーデータで試す
バックアップ・監査ログ・セキュリティ
速さ
短時間で形にする
テストと運用まで含めて仕上げる
初期の動く形は速く作れます。業務で使い続ける品質は、別の工程です。
REVIEW IS THE NEW BOTTLENECK
AIが速くなるほど、
人間のレビュー力が重要になる。
AIが大量に作れるからこそ、判断する力の価値が上がります。
- 正しいか？
- 本当に業務に合うか？
- 危険ではないか？
- 抜けはないか？
- 例外は？
- この画面で現場は使えるか？
「AIが優秀になるほど、人間が何も知らなくてよい」ではありません。
小さな機能のテスト、複数機能の連携、利用者の操作を最初から最後までなぞる確認、権限の境界も、AIにテストを作らせたうえで人が見ます。
WHAT ASAMA AI REALLY DOES
浅間AIの価値は、
コードを書くことだけではありません。
CONSULTING×AI IMPLEMENTATION
現場ヒアリング
課題整理
業務設計
システム構想
AI高速実装
レビュー
現場導入
改善
AIによって、コードやPowerPointを作る時間は大幅に短縮できます。
しかし、成果物の価値を決めるのは
- ・何を問題とするか
- ・業務をどう理解するか
- ・どんな仕組みにするか
- ・どこを人が判断するか
- ・安全に運用できるか
です。
浅間AIは、「AIツールを教えるだけ」でも「コードを書く受託開発だけ」でもなく、業務を理解し、設計し、AIで実装するところまでを一体で支援します。
生産コスト
AIは「価値」を下げるのではなく、
「生産コスト」を下げる
Before
- ヒアリング
- 調査
- 分析
- 構想
- 設計
- 資料化
- 実装
↓ 複数人 × 数日〜数週間
AI-enabled
人間の専門判断 ＋ AI
同じ工程を大幅に高速化
早く作れたから、価値が安くなるわけではありません。
浅間AIが目指しているのは、これまで大企業向けのコンサルティングやシステム開発で提供されることの多かった密度の高い業務整理・設計・改善・実装を、AIによる生産性向上によって中小企業にも届けやすくすることです。
Webの場合
Webアプリの場合は、
実績のある標準構成を使う
これは浅間上昇AIの全アプリ共通スタックではありません。Webアプリにする場合の、標準的な組み合わせです。Desktop から始める案件では使いません。
Next.js
WebサイトやWebアプリを作るための枠組みです。公式サイトと同じ系統で、ページ表示と機能を一体で作れます。
Vercel
作ったものをインターネット上で動かす公開環境です。更新を保存すると、確認環境や本番へ載せられます。
Neon / PostgreSQL
データを整理して保存するしくみです。PostgreSQL は広く使われるデータベース技術、Neon はそのクラウド上の置き場です。
GitHub
プログラムと変更の履歴を保管・共有する場所です。いつ、何を直したかが残り、前の状態に戻せます。
必要に応じて
Resend
フォームや通知のメールを送る
Web Push
スマホなどへ通知を届ける
AI API
文章理解や分類など、AIの処理を接続する
所有
システムを、
顧客側の資産として残す
A｜企業へ直接導入
その企業専用の環境と、専用のデータベース。
B｜士業・代理店など
導入先専用の環境。内部では顧客ごとに分離する。
自社運用
顧客自身が、管理と運用を担います。
浅間上昇AIが運用
資産は顧客側のまま、保守・更新・障害対応を担います。
「所有」と「運営」は別です。
自社のどこを仕組みにするべきか、
まだ決まっていなくても構いません
実践・個別伴走では、「何を作るか」から一緒に整理します。業務ヒアリング → 要件定義 → PoC（試作で方向性を確かめる） → 必要ならアプリ化、という順です。