AIの使い方が、詳しい社員に依存している
一部の社員だけが使いこなし、ほかの担当者へ仕事の進め方を引き継げない。
例えばChatGPTで問い合わせ返信を作れる社員だけが、Shopifyのどの注文情報と社内ルールを渡すべきか知っている。
使うほど会社にデータが蓄積し、AI活用が成長する。
日々の対応・修正・判断を会社のデータとして蓄積。AIが過去の記録を参照し、人の確認と改善を重ねることで、自社の業務に合った活用へ発展させます。
リベレーターズは、既存のExcel・EC・SaaS・基幹システムを活かし、依頼・確認・反映・記録を一つの業務の流れにするアプリを設計・開発します。
一部の社員だけが使いこなし、ほかの担当者へ仕事の進め方を引き継げない。
例えばChatGPTで問い合わせ返信を作れる社員だけが、Shopifyのどの注文情報と社内ルールを渡すべきか知っている。
過去に何を確認し、なぜその対応を選んだか、会社としてたどれない。
例えばkintoneに案件は残る一方、ChatGPTで相談した内容や回答を修正した理由は個人のチャットにしか残っていない。
前回直した内容や社内ルールが次の回答に活かされず、毎回説明し直している。
例えばShopifyの返品に関する返信案で、社内ルールと違う案が出るたびに、担当者が同じ注意事項を付け足している。
誤った候補がそのまま送信・登録されないよう、人が確認する仕組みをつくりたい。
例えばExcelから受注明細を読み取るAIに、確認前の内容をそのままkintoneへ登録させるのは不安がある。
社員の業務画面、会社のデータ、AIをつなぐアプリです。毎回チャットへ資料を貼り付けるだけの運用から、必要な情報を呼び出し、候補を確認・修正し、承認した内容を反映する共通の流れへ変えます。
その過程で、対応・修正・判断理由を会社に残します。担当者が替わっても経緯を参照でき、AIも有効な過去の記録を次の案づくりに活かせます。既製のパッケージを一律に導入するのではなく、対象業務に合わせて設計・開発します。
共通の画面、会社に残す記録、人が判断する工程まで、一つの仕組みとして設計します。今の業務とシステムを確認し、必要な部分からつくります。
上記は業務と支援内容の説明例です。実現方法は、利用環境・契約・権限・接続先の仕様を確認して決めます。
参考: kintoneのデータ取得(2026年10月16日確認)
御社の資料や運用に合わせて設計するアプリの例です。既存のExcelやEC、基幹システムを確認し、残す作業と新しくつなぐ部分を整理します。
いまのExcelへの入力を活かし、拠点ごとのファイル収集・集計から経営ダッシュボードへの反映までをつなぎます。
ファイルを探してまとめる作業を減らし、数字の確認と経営判断に時間を使うことを目指します。
過去の問い合わせ・購入・配送情報を参照し、返信案と対応候補を作るアプリです。
返信の準備を支援し、採用した回答と判断を次の担当者へ引き継ぎます。
PDF・FAX画像・Excelで届く注文を読み取り、基幹システムへの入力候補や取込用CSVを作成します。
古い基幹でも、API・CSVなど使える入出力に合わせて接続方法を検討します。
AIの候補をそのまま反映せず、人の確認とアプリ側の検証を通します。処理した結果まで記録し、次の仕事に使える情報へ戻します。
Excel・EC・基幹と、閲覧できる過去の記録を参照する。
返信案・入力候補を作成。計算や整合確認はプログラムで処理する。
原本と候補を比較し、例外は責任者へ差し戻す。
権限と承認対象を確かめ、送信・取込を実行する。
修正、理由、承認者、実行結果を会社の記録へ保存する。
AIに広い本番更新権限を渡さず、アプリ側で許可された操作・入力形式・承認済みの内容を確認します。承認後に内容が変われば再確認し、権限外や未承認の操作は実行しない構成にします。
送信や取込が失敗した場合に、同じ処理を重複実行しない方法、確認する担当、停止・差し戻し・復旧の手順も設計します。仕組みを置くだけで誤りがなくなるとは考えず、例外を含むテストで確かめます。
ここでいう成長は、過去の記録を参照し、評価と改善を重ねて自社の業務へ合わせることです。データが貯まるだけでAIモデルが自動学習するわけではありません。モデル自体の追加学習が必要な場合は、利用条件・権利・評価を含む別工程として検討します。
新しいアプリを作ること自体を目的にせず、業務に組み込む範囲・残したい記録・実行の制御から選びます。以下は導入方式の比較です。
| 方式 | 検討しやすい条件 | 導入前に確かめること |
|---|---|---|
| 既存AIサービスを業務で使う | 資料整理・下書きなど、現在の画面と運用ルールで仕事が完結する | 利用契約、共有・記録・承認の機能、資料の権限を確認。共通手順で要件を満たせるか試す |
| 既存SaaSを設定・拡張する | 業務とデータが既存SaaSにあり、追加設定や連携で必要な流れを作れる | 承認・履歴・APIの制約、拡張費用、保守担当と契約変更時の影響 |
| AIハブアプリを開発する | 複数のシステムをまたぎ、独自の画面・承認・履歴を一つの業務として扱いたい | 接続の可否、データ設計、必要な画面、開発・運用費と継続的な保守体制 |
製品の選定や、取り組む業務を決める段階ならAI導入支援へ。AIサービスごとの比較は生成AIの比較・選定で扱います。
Excel・EC・kintone・Salesforce・基幹などの入出力を調べ、データの正本、更新頻度、AIへ渡せる項目を決めます。APIが使えない場合もCSV等を検討し、すべての接続先を同じ方式で扱えるとは仮定しません。
売上・利益などの判断に使う情報は、主力事業の経営データ分析基盤へつなげます。特定のシステム接続はMCP開発、導入後の定着はAI運用・定着支援と組み合わせられます。
少数精鋭のチームに、代表がPMとして参加。事業の課題整理から設計・開発・運用まで支援します。
現場の手順・資料・システム、残したい判断、確認と実行の担当を整理します。
成果物業務の流れ、データ・接続先一覧、対象範囲と評価条件
サンプルで出力と修正の負担を確かめ、既存機能を使う部分と開発する部分を決めます。
成果物試作、評価結果、画面・連携・権限の設計と見積もり
AIの候補から業務反映までをつなぎ、入力ミス・権限不足・連携失敗を含めて検証します。
成果物実装、受入テスト結果、公開・停止・復旧の手順
担当者に操作と確認方法を共有。記録の品質・利用状況・修正負担を見て対象を見直します。
成果物操作・引継ぎ資料、運用分担、評価と改善の記録
開発にはClaude Code等も活用しますが、アプリの設計・レビュー・業務確認は担当者が行います。開発ツールの導入はClaude Code導入・開発支援をご覧ください。
対象業務、帳票や画面の種類、データの状態、連携先、権限・承認の複雑さ、必要なテストと研修で変わります。最初の1業務を試す費用と、その後に広げる費用を分けてご提案します。
AIのAPI利用料、保存・検索基盤、既存サービスの費用に加え、資料の更新・品質評価・障害対応を誰が担当するかを確認します。公開後に続けられる構成と保守範囲を、開発前に決めます。
相談時は、繰り返している仕事、使っているExcelやシステム、確認する人、希望する時期を分かる範囲でお知らせください。機密資料を最初から送付する必要はありません。
既存システムを活かす業務画面・連携や、分散した情報をまとめる開発の公開事例です。上記のAIハブアプリの導入実績とは分けてご紹介します。
現在のファイルと運用を確認し、入力を残したまま収集・集計・確認につなぐ方法を検討します。書式の違いや入力漏れなど、処理に必要な条件は事前に整理します。
AIの候補と実行を分け、人の承認後にアプリ側で権限・入力・承認した内容を確認して処理する構成を設計します。誤りをゼロと保証するものではなく、例外・失敗時の検査と停止・復旧手順まで確認します。
利用できるAPIやCSVの入出力、運用ルールを確認して方法を検討します。連携できる項目や更新頻度には制約があるため、調査と試験で対応範囲を決めます。
記録の保存・検索参照と、モデル自体の追加学習は別です。承認済みの対応や有効な資料を次の案づくりに利用し、回答の正しさと修正負担を評価して参照情報・手順を改善します。蓄積量だけで精度向上が保証されるわけではありません。
共通の画面、参照元、確認項目、履歴を用意し、個人の指示だけに依存する状態を減らします。担当者への説明や日々の改善はAI運用・定着支援と組み合わせて進めます。
既存のAIサービスやSaaSで、必要な業務・記録・権限を扱えるなら活用します。複数のシステムをまたぐ処理や独自の承認・画面が必要な場合に、開発する範囲を決めます。
業務への活用方法や製品の更新について、公開されている一次情報をもとに紹介しています。
Hugging FaceがAnyLanguageModel 1.0、swift-huggin…
Papers with CodeはPostgreSQLとpgvectorによるハイブリッド検…
Gradioに組み込まれた新機能gr.Workflowを発表。ノードをつないだグラフとしてA…