― 名刺管理を例として、AI開発の原則と実装を考える
参照実装ノート 第1回：名刺管理・CRM（名刺台帳 / MEISHI DE CRM）
「AIの凄さ」は質問・相談相手としてのチャットから、業務を代行してもらうAIエージェントのフェーズに入ったと言われています。そして、このトレンドには大きく二つの流れがあります。
主流は、AIエージェントに業務そのものを代行してもらう方向です。指示を出せば、AIがその場で処理してくれる、「自動化で楽々、AIが何でもやってくれる」を目指すものです。しかし、より大きな可能性を秘めているのが、「システム開発の民主化」とも呼ぶべき動きで、AIエージェントを活用して中小企業や個人が自らシステムやアプリを「つくる」ことです。
そして、「創造する」ことは本ブログの主要テーマの１つでもあります。今回は、「AIエージェントでつくる」ことについて、実際にわたしが作って利用しているWebアプリを題材として、その原理・原則と実装の実務を解説します。
AIに「やらせる」のか、AIで「つくる」のか
現場の業務視点で見ても、この二つは似ているようで全く異なるアプローチです。AIエージェントに毎回、業務を「やらせる」場合、処理のたびにトークン（※利用量に応じたAI利用権のようなもの）を消費します。そして、AIの動作は統計的な確率に依存するものであり、同じ指示･依頼に対しても毎回まったく同じ結果が返ってくることが保証されていません。
日々の定型業務が実行のたびに少しずつ異なる可能性——これは、業務の土台としては不安定な性質であると言わざるを得ません。
一方、AIにシステムをつくらせるのであれば、確定したプログラム・コードによって業務が実行されることになります。同じ入力には、同じ出力が返る。処理のたびにトークンが消費されることもありません。そして何より、処理の内容がコードとして書かれているので、人間が読み、検証し、履歴を残すことができます。
「AIでつくる」とは、AIの確率論的な振る舞いを、人間が検証できる確実な形式であるプログラム・コードに固定する作業だと言えます。そしてもうひとつの重要な要素として、うまくいかなかったときに、何が手元に残るのかという違いがあります。
AIエージェントでは、思った通りに処理されないとき、指示を書き直したり、依頼し直して、試すしかありません。一方、システムとして開発する場合、挙動がコードとして記述されています。どこで何が起きるか、プログラマーが読んで調べられます。何か改善する必要があったらコードを修正すれば、その改善内容がシステムに資産として積み上がっていきます。
毎回AIにやらせていては、その回の結果だけが返ってきて、プロセスの処理は見えないままのブラックボックスです。将来的なAIエージェント活用のスタイルとしては、実行エージェントと検証エージェントをわけることで、AIエージェント駆動で業務フローを回すことも考えられますが、確実性と検証耐性、トークン消費の両面で見て、現時点では時期尚早と考えています。
「AIにやらせる」か「AIでつくるか」。このアプローチの違いは大きなものがあり、それぞれの使い方、適用するポイントを見極めておくことが重要です。業務視点で見れば、業務の土台は「やらせる」のではなく、「つくる」方を選ぶことになるのは必然でしょう。
何かあったとき、自分たちの手に、調べられるもの・直せるもの・積み上がるものを残しておくことで、システムは中長期で見た自社の資産になります。一方、自社のコントロール外にあるAIエージェントを前提として業務を構築することは、AIベンダーへの依存という大きな負債を負うことになりかねないものです。
わたしは「デジタル主権」を重視する観点から、コードの所有やデータの保存場所について、慎重に観察します。
AIに「まかせる」部分も必要です。こうした前提の上で、「つくらせる」部分をどう作るか。どこをAIに任せ、どこをコードに固めるか。人間はどこを見て何を判断するか。その線引きが、重要な設計判断になるのです。
何をつくるか、どうつくるか
いま、AIを使ってアプリやツールを自作する人が急速に増えています。プログラミングの経験がなくても動くものがすぐにできる。コンピューターの長い歴史を振り返っても、システム開発が民主化される画期的な時代が到来したと言えます。
しかし、とりあえず「動く」ことと、「実務で使える」ことは、同じではありません。 AIで作ることが身近になり、システム開発が民主化されることと、業務で使えるシステムを適切に運用することの間には、まだ一定の距離があります。
実務で使うには、多様な課題や条件をすり合わせる必要があるからです。毎日使うためのUI/UXの作り込み。データはどこに置き、どのデータをつなぐのか。バックアップはどうするのか。そして、運用しながら実務に最適化し続ける仕組みになっているか。考えること、やるべきことが、山のようにあります。
AIで「つくれた」の次に、誰もがこの壁に当たります。そして、AIがどれほど進化しても、これらの問いに正解はありません。会社ごとに使う人のスキルも、実務のポイントも異なるからです。中小企業の業務は、文化も商流も判断の軸も、一社ごとに異なります。他社にとっての最適が、自社にとっての最適とは限らないのです。
ここに中小企業が、自社のシステムを自分で作る意味があります。従来は、システムを開発する難易度が高く、費用も期間も巨額な投資が必要だったため、パッケージソフトやSaaS、ノーコード・ローコードツールが使われてきました。
しかし、これらの手法もまた、複数のツールの乱立による複雑性の増大で現場の負担になっています。
既製品に業務をあわせ、ツールの使い方を覚え、制約の中でデータ交換やカスタマイズする方法を学ぶのは、日々の業務に追われる現場にとって少なくない負荷になります。マスターデータの同期やツール間の互換性管理、膨らみ続けるシート課金、アカウントとサブスク状態の管理、ツールの制約の中でのカスタマイズ、バージョンアップの管理など、その負担も増大し続けています。
こうした状況を解決する策として、自社の現場に最適化したシステムを、AIコーディングで「つくる」という提案が本稿の主旨になります。
どこの会社でも扱うものである『名刺』から顧客管理（CRM, Customer Relationship Management）のシステムを題材として、システムをどのようにつくるか。AIを活用するポイントはどこにあるか。参照実装という形で提示するとともに解説いたします。
参照実装版は、完成品ではありません。そのまま導入するためのものでもありません。「こう考えて、こう作った」という判断の見本であり、みなさんが自分の会社に必要な機能や画面構成を判断するための材料となることを意図したものです。
文末にシステムへのリンクを置いておきますので、実際の動作を確認してみてください。
名刺管理&CRMを題材として
わたしの会社では創業以来、FileMakerと言うデータベースソフトを使って、名刺管理・顧客管理、請求書・納品書発行、ラベル出力、画像・コンテンツ管理など、長年に渡り多様な業務に利用してきました。顧客に納品するシステムでも、図面管理、在庫管理、売上分析・BI基盤など、多様な業務向けソリューションの基盤として活用してきました。
しかし、2026年、AIの劇的な能力向上を受けて、オープンソース系のデータベースとアプリケーション開発環境への移行を進め、業務システムの根幹から刷新を行っています。その最初に手がけたテーマが、名刺管理＆CRMでした。
名刺管理サービスが広く使われるようになった背景には、入力の代行があります。名刺を手入力で打ち込むのは、地味に面倒な作業です。それをマンパワーで肩代わりしてくれることから多くの企業が名刺管理サービスを導入しました。
一方で近年のAIの文字認識、構造化の判断能力の向上は驚くべきものがあります。スキャナからでもスマートフォンの撮影からでも読み取った画像をAIのAPIに渡せば、氏名、会社名、部署、メール、複数の電話番号などが、構造化されたデータになって返ってきます。
わたしは長年、機械学習のAWS Rekognition/Textract/SageMaker、オープンソースのOpenCVなどを使って、画像内の文字やオブジェクトの認識、スキャンした書類の文字起こし等を試してきました。その時、使える最良の道具を揃えて試していましたが、認識の精度や構造化の質は、実務にそのまま使える水準には達しておらず、適用は一部にとどめてきました。
しかし、現在のAIは壁を完全に突き抜けました。今回、名刺管理の業務に適用してみて、これなら使える、多様な場面に活かせると実感しています。
スマホのカメラで撮影して登録すれば、構造化されたテキストとして登録される。
【原則】AIが提案して、人間が決める
前述したようにAIで「名刺管理」のシステム部分を作り、名刺を読み取る仕事——毎回異なる画像からテキストを構造を解析する必要がある部分——は、API経由でAIに「やらせる」という建て付けです。読み取った結果の保存、検索、表示は、指定した自社のデータベースやストレージで行い、自社のサーバーで運用しています。
「未確認 6」——確認済みかどうかが、フィルタできる「状態」として表示する。
入力の自動化、その精度は十分に満足がいくものです。しかし、AIが読み取ったままの状態と、人間が確認した後の状態を、区別して保持しています。一覧画面で確認状態もフィルタするようにしています。
「保存」と「内容を確定する」は、別のボタン。
編集の途中で保存することと、この内容で正しいことを保全することには、異なる意味がある。
AIが提案したタグも、同じ考え方で扱います。AIは「この名刺には、こういうタグが合いそうだ」と提案します。しかし、採用するかどうかは人間が決めます。写真への注釈も同様です。
AIは提案して、採用は人間が行うという基準を守っています。こうしたちょっとした行為によって、人間の記憶にも残りやすくなります。そして、名刺管理・顧客管理、CRMのもっとも重要な目的は、顧客のことを理解することです。
——人間が確認する、顧客の名前の漢字の一字を意識する。実は、こういう部分こそ、UI/UXの隅々で意識して、システム全体に適用して設計することが重要です。
なぜ、そうするのか
これは技術的な選択ではなく、経営上の選択です。AIの読み取りは、全体としては驚くほど正確になりました。しかし、「たぶん合っている」データを、確かめないまま使い続ければ、人間の意識に小さな綻びが生まれます。そして、AIが生成したものと、自社が確認したものを区別できなくなった会社は、自社のデータに責任を持てなくなっていきます。
担当者が確認したかどうかという属性を持つ、ステップをはさむ、ということは意外と重要なことなのです。このことは従来、代行入力サービスを利用する顧客にも提言してきたことでもあります。担当者が自分の担当である顧客の名刺を意識して、データに責任を持つことを忘れてはいけないのです。
UI/UX憲章 ― 原理はどこから来たか
ここまで記載してきた設計は、わたしが長年、システムをつくり続けてきた結果、大切にしている原理・原則です。
2025年12月、「UI/UX憲章 ― 人間の主権を守るための設計原則」として公開しました。中核に置いているのは、三つの概念です。
可観測（Observable） ― システムの状態が、人間に見えること。
可介入（Interruptible） ― 人間が、いつでも止め、割り込めること。
可逆的（Reversible） ― 操作を、取り消せること。
そして、システムの推測や自動判断は、常にユーザーの明示的な意図によって上書き可能でなければならない、と定めました。近年のアプリやシステムは、UI/UXにおいて状態を隠蔽する傾向があり、わたしはこの傾向をたいへん憂慮し懸念しています。そして、この傾向はAIエージェントの普及によって益々、致命的な問題を引き起こす可能性があります。
AIが「よかれと思って」行ったことでも、人間が観測できず、介入もできず、取り消せもしない。その状態を、わたしは危険だと考えています。
AIの基盤モデルの安全性と倫理については、Anthropic社がClaude憲法を制定するなど、メディアでも論じられ、十分とは言えませんが一般の人にも知られてきました。しかし、そのAIを日々の業務システムに組み込む側の設計原則は、まだ十分に語られているとは言えません。
UI/UX憲章は、実装する側から書かれた原理・原則です。これを機会に、AIを実務に、実社会に適用していく上での安全性と倫理、原理・原則、理念・哲学について、広く議論が深まっていくことを願っています。
▼ Anthropic社 Claude 憲法
▼ 然創工学研究所 | UI/UX憲章（全文PDF）
どこで動かし、どこに置くか
― 開発と運用の実務へ
ここまで「AI でつくる」ことを考えてきました。ここまでは、当社で提言している6D戦略の３）Design（UI/UX・設計）に関わる論点でした。
ここからは、１）Domain（領域・文脈）、２）Data（データ）、４）Development（開発）、5）Deployment（運用）、6）Do（実践・行動）です。
AIで「作れた」の先へ進もうとするとき、次に立ちはだかるのが運用です。サーバーはどこで動かすのか。データはどこに置くのか。修正が必要なとき、誰がどのように修正するのか。そして、運用は、開発技術、技術スタックという表現もありますが、技術基盤とも密接に関わるものです。
以下、エンウィットにおける技術選定の基準、実際の運用状況、技術基盤、サーバー構成など、それぞれの判断の理由とともに解説します。
データベース ― PostgreSQL/MariaDB
データベースには、PostgreSQLまたはMariaDBを使います。オープンソースであり、特定の企業のライセンス方針に将来を左右されません。標準的なSQLで、いつでも全データを取り出せます。
顧客との関係の記録は、会社の資産です。 重要なデータは自社の手の届くところに、いつでも移行できる形で保存します。バックアップも標準的な形式（SQLやCSV、JSON等）で扱えるようにしておきます。
なお、わたしは35年以上、FileMakerを業務の中心に使ってきました。中小企業のニーズに十分応える、使い勝手の良い優れたデータベースです。一方で、データ形式は企業固有（プロプライエタリ）であり、長期のデータ保全を考えると、標準形式で取り出せる状態を保つことが課題でした。
FileMakerは古いファイル形式のサポート、コンバート機能も比較的、良心的にサポートされてきたソフトですが、データベースやCADソフト、グラフィックソフトなど、パッケージソフトにおいては、ファイル形式の互換性が失われて、データが使えなくなるリスクを常に内在しています。
こうした状況から現在は、業務システム群のデータベースをPostgreSQL/MariaDBの構成へ、オープンソースと標準データ形式を基盤としたものへと順次移行しています。
長年に渡り、「作りやすい道具」としてFileMakerを利用してきましたが、現在はAIの支援でオープンソースソフトを扱う管理能力、開発力が圧倒的に向上しています。こうした状況から、オープンソースのデータベース、業界標準技術のHTML&CSS、TypeScript/JavaScriptで、システムを構築することが最適であると判断しています。
ストレージ ― Amazon S3
データベースとは別にファイル・オブジェクトを置いておく場所も必要です。今回の名刺管理システムでは、画像や関連ファイルはAmazon S3というストレージサービスに保存しています。S3は、ファイル・オブジェクトを保管するという意味で、セキュリティ、権限管理、高度な保存耐性、バックアップ・アーカイブシステム、共有・分析機能など、あらゆる要求に応えるサービス基盤です。
S3の耐久性は非常に高く、データ耐久性が 99.999999999％、いわゆる「イレブンナイン」になるように設計されており、複数のアベイラビリティーゾーン（物理的に分離されたデータセンター）にまたがって冗長的にデータが保存されます。
実行環境 ― Vercel と AWS
アプリケーションはNext.jsで構築し、Vercelという運用環境で動かしています。Vercelはサーバー構築や保守に人手を割かずに済む構成で、少人数の会社がインフラの専任者なしで運用を回すことができる、使いやすいサービスです。
初期プロトタイプや軽微なシステムにおいては、Vercelはとても扱いやすいサービスです。ただし、システムを本格的に運用するには、拡張性、セキュリティ、メールやストレージ連携など、相互運用性の観点での全体設計を考慮する必要があります。
当社では、システムの運用段階も考慮して、認証（Amazon Cognito）やメール配信（SES）など、VercelとAWSを組み合わせた構成を採用しています。特に認証やメール配信の仕組みは、自作することも可能ですが、パスワードの保管、多要素認証、セッション管理——こうした分野でミスをすると影響が大きく、自作してもあまり差別化にならない領域です。作れるものを、あえて作らないという判断は、何を作るかという判断と、同じくらい重要です。
AWSは現代のデジタルサービス基盤のデファクトスタンダードとなっています。インフラとして、高度で多様なサービス群で構成されていることから、従来、AWSの管理・運用には高度な人材と体制構築が必要でした。しかし、AWSの運用管理もAIが支援してくれるようになり、運用負荷も下がりつつあります。
一般企業には、まだ敷居が高い面もありますが、本格的に実務運用する上では、AWSの活用をお勧めします。
開発の道具 ― IDE、Git、そしてAI
AIにコードを書かせる開発には、AIとの対話ツールだけでなく、統合開発環境エディタ（IDE）が必要です。
わたしは、Cursorを使うことが多いですが、案件によっては、VS Code、Visual Studio、Xcode、Android Studioを使い分けています。iOSアプリにはXcodeが要りますし、AndroidにはAndroid Studioが必要です。WebのHTML/CSS編集には、Pinegrowというソフトを使用しています。
道具は、作るものによっても最適な解がかわります。どれを使うにせよ、基準は同じです。AIが変更したファイルを差分として見ることができ、バージョン管理（Git）の状態を画面で確認できること、いま何が起きているかを、人間が見られることです。
コマンドラインだけで開発することも可能ですが、運用環境との連携や、AIが何をしているか把握する上でも、全体を俯瞰する場としてIDE（統合開発環境）を持つことが重要です。
Gitは、AIとの協働の前提となる重要な技術です。AIが書いたコードを、人間が差分で確認し、問題があればいつでも前の状態に戻せます。先に述べた「可逆的（Reversible）」原則の、開発現場における実装が、Gitによって担保されています。UIの設計原則と、開発スタイルは、同じ思想の二つの側面と言えるでしょう。
通底する基準
データベースはPostgreSQL、データの保存はAmazon S3、運用環境はVercelとAWS、開発はIDEとGit。個別の製品名は、数年後には入れ替わっているかもしれません。しかし、選定と環境構築の基準は変わりません。
人間が、状態を把握できるか。いつでも介入できるか。あとから取り消せるか。
常に意識して、道具や環境を選定しています。
どことどこをつなぐか
名刺は、単体では意味を持ちません。関連する画像やPDF、Webサイト、地図——多様な情報をつないでいくことで、価値が高まっていきます。
「名刺台帳」には、訪問先リストの機能を付けました。名刺の一覧から訪問したい相手をドラッグ＆ドロップで選び、順番を並べ替え、Google Mapsにルートとして送る。出張時の訪問計画を、名刺のデータから直接組み立てるための機能です。
並べ替えや削除もドラッグアンドドロップで。
名刺から訪問先リストを作り、順番を決め、地図へ送る。
失敗と調整
Google Mapsに「社名＋住所」を渡すと、解決される場合と、されない場合があり、完全に期待した通りには動作していません。地図サービスは、社名を場所の名前として照合しようとします。その社名が地図側に登録されていなければ、住所が正しくても「見つかりません」と返ってくることがあります。ビル名の表記ゆれ、支店の表記、法人格の位置——揺らぎの要因は、いくつもあります。
実名義でも、社名＋住所+ビル名の複合クエリは、解決に失敗することがある。
図はデモ用の架空名義の社名なので当然、失敗している。
対策としては、地図へ渡すクエリを住所のみに絞る、あるいは緯度経度で渡す、といった方法を試みて、調整を続けています。住所だけにすれば、ルートとしては認識されるようになります。
住所だけにすると、ルートとして認識されている。
つなぐこと
参照実装が示すべきは、成功例ではなく、判断と試行の記録だと考えています。
AIで作れるようになった後にぶつかるのは、まさにこういう「つないだら、うまくいかない」の連続だからです。
なお、デモのサンプルデータでは、架空の会社に、実在する公園・緑地の公表住所を割り当てています。地図連携を実際に試せて、かつ、誰の実住所も使わない。ダミーデータの設計もまた、「何を見せ、何を伏せるか」という設計判断の事例です。
何を捨てるか
作れる人は、機能の足し方を知っています。難しいのは、引き算です。何を載せないかを決めることは、何を載せるかを決めることと同じくらい、そのシステムの性格を決めます。
わたしが、中小企業の名刺管理やCRMでは優先度が低く、推奨していない機能とその考え方を3つ紹介します。
1．案件の確度
CRM/SFAには定番の機能として、案件の確度を管理し、営業担当者ごとの成績と紐づけるものがあります。
当社自身は少人数の会社で業務の性質としても、そもそも必要がないという面もあるのですが、顧客にもこうした管理はあまり推奨していません。
理由は二つあります。
ひとつは、行動が管理されていると感じたとき、人間の潜在意識は、恐怖と不安から動くようになることが挙げられます。数字を作るために動き、管理者に説明できる行動を選ぶようになる。それは、顧客のために動くことからずれていきます。
ふたつめは、営業成績と連動したシステムは、顧客志向ではなく、成績志向の文化を育てます。誰のために働いているのかが、少しずつ入れ替わっていく。システムは、人間の意識をつくるのです。
UI/UX憲章では、システムが人間の理解・制御・選択の権利を奪ってはならない、と定めました。これはエンドユーザーだけの話ではありません。業務システムを毎日使う社員にとって、そのシステムは、日々の判断を規定する環境となります。
——営業が何十人もいて、生産計画とのパイプライン等から案件の確度管理が経営上不可欠な会社もあるでしょう。業務上有効な機能は活用するべきですが、ただ導入したSaaSにあるから、と漫然と使っても経営的な効果は期待できません。また、こういう機能は得てして、管理のための管理仕事を増やしがちで、現場の判断疲れや負荷につながることもあるので、注意が必要です。
2. 大企業向けの統制・監査機能
業務システムには、定番の統制機構もあります。役割ごとの細かい権限マトリクス、承認ワークフロー、監査ログ、SSO。これらも運用上の負荷が大きい機能です。
権限マトリクスや監査ログは、「組織の内部にも信用できない者がいるかもしれない」という前提のうえに設計されています。従業員が数千人いる組織では、それは正しい前提です。しかし、大多数の中小企業にとって、運用負荷の大きい統制・監査機構は省略しても良い機能です。
一方、外部からの脅威は、会社の規模に関係なく存在します。認証基盤（Amazon Cognitoなど）を使うことや、社内システムとしてIPアドレスによるアクセス制限をかけることなど、ポイントを絞った対策が必要です。
何を守るのかを決めずに機能だけを揃えても、守りにはなりません。セキュリティ設計は、脅威モデルを自社の言葉で書くことです。
——こうした判断も各社固有の判断基準がいるはずです。中小企業でも、大企業を取引先に持っていて監査を求められる会社、認証取得が必要な会社では、そもそも監査・統制機能を持つSaaSを選択する必要があるかもしれません。
しかし、過剰な品質要求や管理の細かさが、現場の負担になり、活力を削いでしまうことになりかねないことには注意が必要です。
3. 自動更新
名刺には、人の名前と、組織の名前が書かれており、すでに登録されている人や組織と照合することができます。一致すれば、自動的に紐づける——技術的には、可能なことです。しかし、「自動化」は気をつけないといけない機能です。
今回の参照実装版では、名刺を取り込むと、既存の人物・組織との一致候補が検出され、登録前の確認画面に表示されます。緑は既存へのリンク、青は新規登録。「既存の人物『◯◯』にリンクします」と、システムはこれから行うことを説明します。しかし、担当者が確認して登録ボタンを押すまで実行はしません。
システムの検出結果を確認して、担当者が『登録』を押す。
緑＝既存にリンク、青＝新規登録
同姓同名も、同じ名前の別会社のの可能性もあります。転職して、同じ人物が別の組織に現れることもあるでしょう。AIは、画面の中の情報しか見ていませんが、人間はその人と会ったことを覚えています。
提案はするが、自動で実行はしない。——ここでも、人間が確認のステップを入れる方式です。
つくる人のつくり方
中小企業の業務は、文化も商流も、判断の軸も、会社ごとに異なっていることが多いものです。
汎用のソフトウェアを利用している場合、その違いをカスタマイズで吸収することになります。そして、カスタマイズが重なるほど、標準ソフトとしての利点が薄れていきます。一方で、従来はゼロから作る開発（いわゆるフルスクラッチ）には高額な費用が必要で、中小企業が取り組むには荷が重すぎました。
多くの会社が、パッケージソフトやSaaS、ノーコード・ローコードツールを利用せざるを得なかった理由です。しかし、AIの支援によって作ることの負荷が劇的に下がり、新たな選択肢が生まれました。
しかし、何を作るか。どう作るか。何を捨てるか。データをどこに置き、何とつなぐか——決めるべきことは、何ひとつ減っていません。むしろ、作れるようになったからこそ、判断の重みが増したと言えるでしょう。
つくる人が、どうつくるか。その事例をオープンにすることが、つくる人をつくることに役に立つはずだと考えています。そして、中小企業の現場、実状に鑑み、どのような考え方でシステムをつくるか、そうしたことをみなさんと考えていきたいと思います。ぜひ、参照実装版をさわってみて、ご意見やご要望をお寄せください。
参照実装をさわる
- enGeneオンライン会員（無料）：参照実装版を機能制限付きで実際に操作できます
- enGeneメンバー（有料）：エンウィットが実際に業務で使用しているものと同じシステムを利用できます
セキュリティ上、完全なオープンアクセスにしてしまうわけにもいかないので、ご面倒ですが登録をお願いします。
▼ enGeneオンライン会員（無料）サインアップ
メールアドレスでサインアップすると確認メールが届きますので、登録を完了してください。登録完了して一度、オンライン会員になると、今後増えていく参照実装版・デモ版へのアクセスも可能になります。
▼ 参照実装デモ「名刺台帳（MEISHI DE CRM）」
今後、名刺管理・CRMに続き、請求・納品管理、画像データベース、コンテンツ管理などを、参照実装として順次公開していく予定です。
まだ、自社の形に合わせて作り込むには、6D戦略フレームワークに基づいて、実践していくことが有効です。当社では、セミナー、コンサルティング、勉強会、伴走支援など、貴社の状況にマッチした形で、AI・DX・デジタル戦略を推進するサービスを用意しています。お気軽にご相談、ご参加ください。
▼ enGene Open Lab Ginza
▼ 6D戦略とは
本稿で扱った論点は、当社が提唱する6D戦略フレームワークに対応しています。何をつくるか（Domain）、データをどこに置くか（Data）、UI/UXをどう設計するか（Design）、どうつくるか（Development）、どこで動かすか（Deployment）、そして実践し改善し続けること（Do）。
AI/DX時代、デジタル戦略に6Dの視点、統合する視野の重要性が高まっています。参照実装ノートは、この6つの領域をシステムとして実装する際の指針となることを意図した試みです。今後のシリーズも、6D戦略の統合的なフレームワークと実務の接点となることを目指して、書き進めていきます。
6D戦略については以下のページで解説していますので、参照ください。
▼ 然創工学研究所について
▼ 取材・執筆・講演のご依頼について
