Menu Close

オントロジーとAIエージェントを活用した企業クラスのアプリケーション開発

translated from Korean by Google

1 概要
2 開発プロセス
     2.1 業務分析
     2.2 業務モデリング
     2.3 オントロジー
     2.4 アプリケーション設計
         2.4.1 UMLベースの設計
         2.4.2 アーキテクチャ意思決定(Archtectural Decision)
3 開発結果
     3.1 フロントアーキテクチャ
         3.1.1 ユーザー体験フレームワーク
         3.1.2 ユーザーインターフェース
         3.1.3 ユーザインタフェースロジック
         3.1.4 バックエンドインタフェース
     3.2 バックエンドアーキテクチャ
         3.2.1 アプリケーションプログラムインタフェース(API)
         3.2.2 データ転送オブジェクト(DTO)
         3.2.3 アプリケーションサービス
         3.2.4 ドメインサービス
         3.2.5 リポジトリサービス
     3.3オントロジーセマンティッククエリーとレスポンス
4回顧問

急速に進化するソフトウェアエンジニアリング環境では、人工知能は開発効率を飛躍的に向上させる前例のない機会を生み出します。この記事では、オントロジーとAIエージェントの戦略的な実装を通じて、エンタープライズクラスのアプリケーション開発に革新をもたらした画期的なケーススタディについて説明します。このアプローチは、ビジネス要件が機能的なソフトウェアに変換される方法を根本的に再構築し、リリース期間、ビジネスの俊敏性、品質保証、およびコスト削減の面で大きな改善を達成しました。

この変化の中心には、ビジネス文書を分析し、29の観点から包括的なビジネスオントロジーを構築するための洗練された方法論がありました。この多次元オントロジーは、アプリケーション全体のエコシステム構築の意味論的基盤となり、AIエージェントが複雑なビジネスルールと関係を深いコンテキストレベルで理解できるようにしました。この実装では、ユーザーインターフェイスコンポーネントからバックエンドアプリケーションロジックまで、インテリジェントなシステム設計に必要な構造フレームワークを提供するグラフベースのオントロジーサーバーを利用しました。

このケーススタディは、初期ローンの申請から返済の回収まで、ライフサイクル全体にわたる住宅ローン管理システム全体に焦点を当てています。この分野は、伝統的に多数の規制上の考慮事項、リスクアセスメントフレームワーク、顧客インタラクションポイントを持つ複雑なビジネスプロセスを表します。オントロジーベースのアプローチにより、システムはこの複雑さを一貫した知識モデルにデジタル化し、AIエージェントが解釈して推論して実行可能なアプリケーションコンポーネントに変換できるようになりました。

最も注目すべき点は、このアプローチによって開発スケジュールを劇的に短縮することができたことです。最初のビジネス理解から展開全体まで、プロセスはわずか3日で完了しました。これは単なる漸進的な改善ではなく、エンタープライズソフトウェアの提供の可能性の革新的な再調整を意味します。

この記事では、この革新を可能にしたアーキテクチャの原則、オントロジーモデリング技術、AIエージェントの動作について説明します。 29の観点からのオントロジーの具体的な構成、グラフベースの知識サーバーの技術的実装、アプリケーションスタック全体を生成した自動化された設計プロセスを見てみましょう。また、開発効率の側面の定量的パフォーマンスと、システムの品質とビジネスの整合性の側面の質的改善の両方を分析します。これらの分析は、ソフトウェアエンジニアリング慣行で同様の革新能力を追求する組織に青写真を提供したいと考えています。

1. 概要

急速に進化する今日のデジタル環境では、企業は戦略的ビジョンを運用現実に変えるための前例のない課題に直面しています。ビジネスオントロジーベースのアプローチは、企業能力評価、ビジネス能力実現、ビジネスモデルイノベーション、デジタル/AI移行、バリューマイニング/データ収益化、ドメイン知識管理、意思決定管理、アプリケーション開発、データガバナンスなど、さまざまな方法で重要なビジネス実行領域を革新するための包括的なフレームワークを提供できるようにします。この記事では、特に他のすべてのイノベーションシナリオを最終的にデジタル領域で実現できるようにする基礎となるアプリケーション開発に焦点を当てます。

アプリケーション開発は、9つのイノベーションシナリオでユニークな交差点に立っています。他の分野では、ビジネス能力、モデル、意思決定フレームワークを概念化することができますが、アプリケーション開発はこれらの概念をデジタルシステムを通じて実現する重要な実装段階です。ビジネスオントロジーに基づく効果的なアプリケーション開発方法がなければ、どんなに洗練されたビジネス戦略も理論的構造にとどまり、デジタル中心の経済において実質的な価値を提供することはできません。デジタル時代のビジネス実行は、デジタル実装と不可分の関係にあるという基本的な前提は単純ですが強力です。

オントロジーアプローチとアプリケーション開発の統合は、組織がソフトウェアソリューションを構想、設計、実装する方法にパラダイムの変化をもたらします。従来のアプリケーション開発は、ビジネスステークホルダーからテクノロジー実装チームに移動し、ビジネス要件が歪む「翻訳中の損失」の現象に苦しむことがよくあります。ビジネスオントロジーは、ドメイン知識を機械可読形式でキャプチャする構造化されたセマンティックベースを提供し、ビジネスと技術の利害関係者間で共有言語を生成します。このセマンティックブリッジにより、AIベースの開発ツールは、開発ライフサイクルを通してビジネス意図に忠実性を維持できます。

アプリケーション開発がうまく構築されたビジネスオントロジーの案内を受けると、組織は本質的にビジネス運営と連携したシステムを開発する能力を備えています。オントロジーベースのアプローチにより、既存のプロセスを自動化するアプリケーションを作成するのではなく、ビジネス知識を実装し、変化する条件に適応し、ドメインの専門知識に基づいた意思決定支援を提供するシステムを簡単に作成できます。その結果、トランザクションを実行するだけでなく、ビジネスインテリジェンス、運用柔軟性、戦略的優位性に積極的に貢献するアプリケーションが誕生し、単純な技術的アーティファクトではなく、ビジネス能力のデジタル表現になります。

オントロジーベースのアプリケーション開発の利点は、技術分野を超えてコアビジネス価値の創造にまで広がっています。ビジネスコンセプト、関係、ルールを本質的に理解するアプリケーションを作成することで、組織は戦略の策定と実行の間の実装のギャップを大幅に減らすことができます。このアプローチは、市場の変化に迅速に適応し、知識をより効果的に保存し、意思決定の質を向上させ、ビジネスと技術の連携を強化することができます。さらに、オントロジーベースのアプリケーションは、ドメインの知識を明示的、機械的に処理し、AIの強化に使用できるようにすることで、継続的な革新のための基盤を構築します。

次のセクションでは、ビジネスオントロジーとAI技術を組み合わせてアプリケーション開発慣行を革新する方法について説明します。知識の抽出と形式化のための方法論、オントロジーベースのソフトウェアエンジニアリング技術、セマンティックデータ統合のためのアプローチ、アプリケーションのライフサイクル全体にわたってオントロジーソートを維持するためのフレームワークについて説明します。実際のケースと実装パターンは、このアプローチがアプリケーション開発自体を革新するだけでなく、ビジネスオントロジーエコシステムの他の8つのイノベーションシナリオのための重要な原動力となり、最終的に真のデジタルビジネス革新の約束を果たす方法を示しています。

[図1]オントロジーベースの事業および業務革新のシナリオ

2.  開発プロセス

本資料のプロジェクトでは、最大のオントロジーとAIエージェントを活用した企業クラスのアプリケーション開発可能性を探索するための実験プロジェクトだったため、いくつかの原則を置いて進めました。その原則は次のとおりです。

1) 可能人間介入最小限える。つまり、業務分析から最終コード完成までヒューマン介入なしに進めるようにするのです。しかし、アーキテクチャの決定は、目的のアーキテクチャと実装の制約を決定することであるため、プロジェクトの進行者は決定要素を定義しました。アーキテクチャは84の決定要素を特定し、84のアーキテクチャ決定要素の決定をAIエージェントに渡しました。これには、さまざまなライティング標準などの標準化基準も含まれます。

2) 可能現実使用する業務文書要求事項加減なくそのまま使用する。つまり、本プロジェクトのために別途の業務文書をフォーマットまたは作成することなく、現実で使用する業務文書を100%そのまま使用しました。そのような文書をマンション分譲事務所で求めているそのまま使用しました。そのマンション中めっきローン契約関連文書は約76ページに及ぶ実際の文書であり、この文書から分析業務モデル、オントロジー要素、公理(Axiom)を抽出してそのままオントロジー構築、アプリケーション設計とコード完成に使用しました。

3) 一貫性けているかけている部分については、AIエージェントの能力活用して補完する たとえば、現実の文書には一貫性が欠けている部分もあり、欠けている部分もあります。オントロジーでは概念の定義と公理が重要であり、一部のオントロジー要素について文書ではその定義を見つけることができた場合があり、そのためにはエージェントの推論能力が活用されました。

4) すべての作業(アーキテクチャ決定AIエージェントが必要があります。この前提のため、これは単なる開発ではなく、AIエージェントを訓練するプロセスとして、エージェントがソフトウェア開発プロセスを理解して適用する訓練です。その期間は、本プロジェクトの前に約1ヶ月かかり、その期間内のテスト期間にその能力を補完し続けました。したがって、1ヶ月のエージェント開発期間、そして実際のプロジェクトは3日であれば分析からコード完成まで進めることができるようになりました。 3日の期間中には1.5日程度が分析とモデリングにかかり、設計には約0.5日そしてコード完成に約1日かかりました。各段階で強力な品質監査エージェントが介入して品質確認を行うようにし、各オントロジー要素、各分析、設計、完成したコード間の一貫性監査を徹底するようにしました。

5) 実行されても完成したコードは、再作業時じプログラム構造名称使用しなければならない AIを活用してプログラムを作成すると、繰り返すたびに結果が異なる場合があります。つまり、プログラムの構造、プログラムで使用される各種名称などが異なる混乱を与える場合があるため、開発周期が繰り返されても同じプログラム構造と名称が使用されるようにしました。

6) バイブコーディングではなくエンジニアリング方法適用します 前述のバイブコーディングの経験を共有したように、バイブコーディングには多くの制限があります。その中で最も大きな問題は、バイブコーディングによるプログラムサイズやアプリケーションの複雑さが増すにつれて、プログラムやモジュール間の一貫性の維持が難しくなり、頻繁にリファクタリングが必要であり、これによってアプリケーション全体の体系が崩れる場合があります。このような問題としては、企業クラスのアプリケーションを開発できず、今後のメンテナンスやメンテナンスができないため、エンジニアリングアプローチを採用しています。このようなエンジニアリング手法によるエンタープライズクラスのアプリケーション開発には、エンジニアリング手法とアーキテクチャ決定を体系的に定義し、エージェントを訓練する必要があります。これはジュニア開発者を採用して上級開発者を作る過程と同じであると見なされます。このようなエンジニアリング方式を通じて開発することで、繰り返し可能で持続可能な開発がなされるようになりました。

これらの原則のもとで開発された成果物は、約4,500個のオントロジー要素、約29個のワークフロー、107個の業務措置(Action)、42個の画面、108個の業務エンティティ、64個の業務イベント、69個のコードテーブル、153個の制約事項、101 13の価格決定規則、50の検証規則、約2,000以上のプログラムコードが完成しました。これには、最下位の要素の1つであるコードインスタンス、検証ルール、業務制約、データセキュリティ、承認権限、およびさまざまな業務ルールまで含まれていました。アプリケーションは、マンション中めっきローン商品紹介、顧客確保、顧客脆弱性評価、ローン申請、担保評価および設定、ローン承認、ローン返済、リスク管理およびコンプライアンス管理まで、全ライフサイクルがカバーされました。

エンタープライズクラスのアプリケーション開発は、従来のコーディング作業を超える重大な課題を抱えています。知識、仮定、実装アプローチが初期の構想と最終的な提供の間でしばしば変わるため、繰り返しの開発サイクルで一貫性を維持することは依然として困難な問題です。従来のプロンプトベースのAI開発は、1つの変更が複数のコンポーネントに影響を与える可能性があるエンタープライズシステムの複雑な相互依存性に対処するには欠けています。さらに、エンタープライズアプリケーションに必要な関連情報の量は、標準のAIシステムのコンテキストウィンドウと注意力を超えており、すべてのビジネス要件の完全性を確保するには、一般的な開発パラダイムを超える専門的なアプローチが必要です。

したがって、[図-2]のような体系的な方法を使用しました。

1) オントロジーベースの分析

これらの暗黙の複雑さを解決するために、オントロジー中心のアプローチは、ビジネスおよび要件文書を慎重に処理する専門的な分析およびモデリングエージェントから始まります。これらのAIエージェントは、主な概念、関係、制約、およびプロセスを抽出して、非定型ビジネスナラティブを整形化モデルに変換します。この初期段階では、洗練された自然言語処理、セマンティック分析、知識抽出技術により、ビジネスドメインの基本的な理解を確立します。従来の要件分析とは異なり、これらのエージェントは、機械が解釈可能な表現を生成し、その後のすべての開発活動を導く包括的な知識構造の基礎を形成します。

2)多視点ビジネスモデリング

分析フェーズでは、エンタープライズアーキテクチャ全体を包括的に把握できる29の視点モデルを作成します。これらの視点は、ビジネス能力、組織構造、プロセス、情報フロー、システム、技術、セキュリティ問題、コンプライアンス要件、その他の重要な次元を網羅しています。各モデルは、最高経営陣から技術専門家まで、特定の利害関係者に最適化された専門化された視点を提供します。このアプローチの強みは、これらの視点間の意味的な接続を維持し、あるモデルにマッピングされたビジネスプロセスが他のモデルで表現されたデータエンティティ、役割、および技術コンポーネントと正しく関連付けられるようにすることで、企業に対する一貫した多次元の理解を生み出すことです。

3) オントロジー統合とセマンティック強化

個々のモデルが成熟すると、包括的なエンタープライズオントロジーに統合されるプロセスを経ます。このプロセスは、単純な図の組み合わせではなく、モデル要素が意味のある関係を介して接続される洗練された意味の強化です。オントロジーは、「プロセスはリソースを消費する」、「部門は能力を担当する」、「システムは機能を実装する」など、正確な意味を表現するタイプ化された関係を通じて、連結されたエンティティを持つ知識グラフに成長します。この意味論的リッチは、一般的なモデルリポジトリをはるかに超えた推論能力を可能にし、自動化された一貫性チェック、影響分析、インテリジェントクエリを可能にします。エンタープライズオントロジーは、組織のビジネスと技術環境の生きたデジタルツインになります。

4)プロジェクトのためのオントロジーパーティション化

特定のプロジェクトを開始すると、エンタープライズオントロジーの関連部分を体系的に識別して抽出し、プロジェクト固有のオントロジーを作成します。このスコーピングプロセスは、プロジェクトに必要な主な要素だけでなく、依存関係、関連規制、利害関係者の懸念、および以前のイニシアチブの歴史的文脈を識別します。このように作成されたプロジェクトオントロジーは、より広範なエンタープライズコンテキストとの接続を維持しながら、開発努力に対する意味論的に正確な境界を提供します。このアプローチは、プロジェクトがエンタープライズ標準に準拠した状態を維持しながら、提供される特定のビジネス能力にリソースを集中できるようにします。

5) プロジェクト範囲の設定と検証

開発を始める前に、プロジェクトのオントロジーはセマンティック推論エンジンを通じて厳格な検証を受けます。これらのエンジンは論理ルールを適用して不一致を検出し、ギャップを識別し、定義された範囲の完全性を保証します。たとえば、自動化された推論エンジンは、提案されたビジネスプロセスに必要なデータ入力が不足しているか、セキュリティ要件がアクセシビリティ義務と矛盾しているか、または技術コンポーネントに必要な能力が不足していることを識別できます。これらの検証は、単純な構文チェックを超えて、ビジネスロジック自体の意味論的検証に拡張されます。このアプローチは、開発前の不整合と完全性の問題を解決することで、コストのかかるプロジェクトの中程度の変更と再調整を大幅に削減します。

6) マルチエージェント共同開発

開発プロセスでは、実績のある入力に基づいて、プロのAIエージェントが協力してビジネス要件を正しく機能するソフトウェアに切り替えます。 UXデザイナーはオントロジーからユーザーの旅程を抽出し、最適な経験フローを作成します。 UIデザイナーは、オントロジーに保存されている企業アイデンティティのガイドラインに合わせて、ワイヤフレームとビジュアルデザインに変換します。アプリケーション設計者は、エンタープライズ標準に準拠した技術パターンを確立します。データベース設計者は、情報モデルを最適化されたスキーマに変換します。各エージェントは同じオントロジーベースで作業するため、すべての開発成果物にわたって一貫性を維持しながら、特定の問題にドメイン固有の専門知識を適用できます。

開発ライフサイクル全体のオントロジーは、伝統的にサイロ化された関心事全体で一貫性を維持する中央調整メカニズムとして機能します。ビジネスアナリストがプロセス要件を更新すると、オントロジーは影響を受けるユーザーインターフェイス、データ構造、セキュリティ制御、およびテストケースに意味を伝播します。これらの変更の自動伝播は、すべての開発成果物が同期されたままになることを保証します。このアプローチは、すべての開発者とAIアシスタントが自然言語の要件を解釈するのではなく、意味論的に正確な同じオントロジー定義を参照するため、さまざまなシステムコンポーネントで要件が異なる方法で実装される一般的な問題を大幅に削減します。

開発が進むにつれて、実装アーティファクトはビジネス意図のオントロジー表現と比較して継続的に検証されます。開発エージェントによって生成されたコードは、単に構文の正確性だけでなく、ビジネス要件との意味的な一致も確認されます。たとえば、データアクセスコンポーネントがオントロジーで定義されているすべての必須セキュリティ制約を適用していることを自動的に検証できます。これらの継続的な検証は、ビジネスの意図と実装の間の不整合をプロセスの早い段階で捉え、統合テスト中または本番使用中にこれらの問題を発見するのに多大なコストをかけることを防ぎます。

テストケースデザイナーエージェントはオントロジーを活用して、技術的正確性とビジネスルールの遵守の両方を検証する包括的なテストシナリオを作成します。オントロジーには、ビジネスルール、制約、および期待される動作の正式な定義が含まれているため、実装がこれらの意味を正しく適用することを確認するためのテストケースを自動的に生成できます。品質監査エージェントは、オントロジーでエンコードされたエンタープライズ標準とベストプラクティスの継続的なレビューを行います。このアプローチは、テストが「システムが構築されたとおりに機能しているか」を確認することを超えて、「システムがビジネスが意図したとおりに動作している」ことを確認することで、提供されるソリューションのビジネス価値を劇的に改善します。

開発が完了すると、プロジェクトチームは構築されたシステムをビジネスおよび技術用語で文書化するアプリケーションオントロジーを作成します。このオントロジーは、最終的な実装決定をキャプチャして元のビジネス要件に再マッピングし、これらの要件がどのように満たされたかを文書化します。アプリケーションオントロジーには、運用パラメータ、監視ポイント、一般的なサポートシナリオなどのランタイムの側面が含まれます。この包括的なナレッジストアは、ライフサイクル全体を通してアプリケーションへの最終的な参照として機能し、システムの構造と動作に関する正確なセマンティック情報を使用して、メンテナンス、改善、および最終的な交換活動をサポートします。

7)セマンティック質問回答システム

アプリケーションオントロジーは、最終的にビジネスや技術的観点からアプリケーションに関する複雑な質問に答えることができるドメインエキスパートシステムを強化します。ユーザーは、「このデータフィールドを変更するとどのビジネスプロセスに影響しますか?」あるいは、「この機能に適用されるコンプライアンス規則は何ですか?」などの自然言語の質問を投げることもできます。このシステムは、オントロジーの豊富なセマンティクスを活用してアプリケーションのさまざまな側面を接続し、状況に適切で正確な答えを提供します。この能力は、知識伝達を劇的に改善し、運用意思決定を支援し、将来のシステム進化のための重要な洞察を提供し、初期の概念から運用支援までの意味論的正確性を維持する開発アプローチを完成させます。

[図2]企業クラスのアプリケーション開発の文脈

2.1  業務分析

ビジネス分析はアプリケーション開発の基本的な柱として機能し、ビジネス運営をリードする重要な要件を体系的に識別、レビュー、文書化します。今日のデジタル環境における効果的な分析には、既存のプロセスの単純な文書化を超えて、隠された概念、未定義の関係、存在するが明確に表現されていない未開拓のビジネスドメインを見つけることが含まれます。ビジネス分析は、組織的な調査を通じて、組織の運用フレームワーク、利害関係者のニーズ、戦略的目標の包括的な理解を構築します。この重要な最初のステップは、将来のすべての開発活動が構築される概念的な基盤を築き、技術ソリューションが認識された要件ではなく、真のビジネス要件を満たすようにすることです。

徹底したビジネス分析の重要性は、アプリケーションの効率性と組織の価値創造に直接関連しているため、いくら強調しても過度ではありません。分析が表面的または不完全な場合、アプリケーションは技術的な卓越性にかかわらず、重要なビジネス課題を解決できません。逆に、以前に定義されていなかった概念と関係を明らかにする包括的な分析により、組織は既存のプロセスを単純にデジタル化するのにとどまらず、運用を革新するソリューションを開発できます。これらの探索的分析により、企業は変化する市場状況に適応し、競争上の優位性を特定し、見えない機会を認識できます。ビジネス分析の豊富さと深さは、意味のあるビジネス価値と持続可能な競争優位性を提供できるアプリケーションの能力を直接決定します。

現代の分析環境では、AIベースのビジネス分析エージェントは、組織が運用領域を探索して定義する方法を革新的に変えました。これらの専門化されたデジタルエンティティはドメイン固有の専門知識を持っており、膨大な量の情報を処理し、パターンを識別し、人間のアナリストだけでは不可能な規模と速度でビジネスコンセプトを見つけることができます。プロセス分析エージェントはワークフローをマッピングし、非効率性を把握し、価値分析エージェントは利害関係者の優先順位と満たされていない要件を定量化し、エンティティ分析エージェントはコアビジネスコンセプトとその関係を発見し定義し、規制エージェントは複雑なコンプライアンス要件を満たすことを保証します。これらの専門分析エージェントが一緒に集まり、従来の方法では得られなかったインサイトを生成できる包括的な分析エコシステムを形成します。

これらの分析エージェントの特徴は、概念発見能力、つまりビジネスドメイン内で機能する名前のない要素または未定義の要素を検出する能力です。これらのエージェントは、単に明示的な知識を文書化するのではなく、洗練されたパターン認識、意味分析、推論推論を通じて存在するが正式な定義を持たない暗黙の概念を識別します。分析エージェントは、以前は見られなかったこれらの要素の名前を指定、定義、公開することで、アプリケーション開発に使用できる概念的な環境を劇的に拡張します。これらの概念的な拡張は、既知のビジネス要件だけでなく、ステークホルダーがまだ表現していない潜在的な要件に対処するより包括的なデジタルソリューションにつながります。その結果、ビジネスのより深い理解、運用関連性、革新的な価値を提供するための強化された能力を示すアプリケーションが生まれます。

2.2  業務モデリング

ビジネス分析モデルはアプリケーション開発の基本的なフレームワークとして機能し、目に見えるビジネスコンセプトと隠されたビジネスコンセプトを体系的に捉えます。この29のモデルは、ステークホルダーのバリューチェーンから組織の責任まですべてを網羅するビジネスエコシステムの包括的なデジタル表現を生み出します。価値提案、能力要件、製造プロセス、配信メカニズム、交換プロトコルなど、さまざまなレンズを介してビジネスプロセスを調査することで、このモデルは以前に検出されなかったビジネスコンセプトを識別、命名、定義、およびアプリケーションアーキテクチャに統合できます。これらの徹底的な概念探索は、結果のアプリケーションの豊かさと効率を直接決定します。

生のビジネス分析から構造化モデルへの移行は、概念の識別と関係マッピングという高度なプロセスを通じて行われます。当初は、利害関係者のインタビューとプロセスの観察を通じて、ビジネス運営に関する非定型情報を取得します。この情報は関連モデルにまとめられて徐々に具体化され、各モデルは人間と機械の相互作用から組織の役割の説明まで、ビジネスのさまざまな側面に焦点を当てています。変換プロセスは、ビジネス概念を適切なモデルに体系的に分類し、同時に複数のモデルにわたって関連概念間の重要な接続を確立し、アプリケーション開発の青写真として機能するビジネス環境を一貫して表現します。

これらのモデルは、ビジネスエコシステムの明確で互いに接続された側面に焦点を当てています。価値指向モデルは、ビジネスがさまざまな利害関係者と価値を創造、製造、伝達、交換する方法を捉えます。能力モデルは、これらの価値を実現するために必要なリソース、技術、資産を識別します。相互作用モデルは、ビジネスプロセス全体にわたって人が機械やシステムと通信する方法をマッピングします。組織モデルは、ビジネス部門間の役割、責任、関係を定義します。これらのモデルを組み合わせることで、運用と戦略的なビジネスレベルを包括的に把握することができ、強力なアプリケーション開発に不可欠な以前は隠されていた概念と関係を明らかにする多面的な視点を得ることができます。

専門化されたAIモデリングエージェントは、この分析プロセスを革新し、各モデリングレベルでドメインの専門知識を提供します。バリューモデラーエージェントはコアバリュー提案と交換を識別し、プロセスモデラーはワークフローと意思決定ポイントをマッピングします。ビジネスエンティティモデラーはデータ関係とライフサイクル状態をキャプチャし、UXモデラーはユーザーの対話と経験の旅に焦点を当てています。コンプライアンスモデラーは規制要件が適切に統合されていることを確認し、価値提案モデラーはビジネスの市場オファリングを改善します。このプロセスでは、品質監査エージェントは各モデルに厳格な基準を適用して、完全性、一貫性、ビジネス目標との連携を検証します。これらのプロフェッショナルエージェントは、結果モデルがビジネス要件を真に解決する成功したアプリケーション開発を導くために必要な深さと品質を達成できるように包括的に保証します。

2.3  オントロジー

ローン処理のオントロジーには、ローン商品、申請者プロファイル、財務指標、規制要件、リスク評価基準、ビジネスプロセスワークフローなど、すべての必須ドメイン知識を捉える包括的な意味構造が含まれています。貸し手、保証人、貸主、担保資産、信用スコア、融資条件、返済スケジュールなどのオブジェクト間の関係を正式に定義します。また、ローンの開始とサービスプロセスを管理するビジネスルール、コンプライアンスパラメータ、承認ワークフロー、意思決定基準も統合されています。この豊富なセマンティックフレームワークは、静的情報を表すだけでなく、ローン運用を特徴付ける複雑な条件関係と依存関係を実装します。

ローンアプリケーション開発の基盤として、このオントロジーの堅牢性は、部門別サイロとシステム境界を超える単一のソースを提供する能力から来ています。分析とモデリングの結果を一貫したグラフモデルに同期させることで、オントロジーは通常、複雑なソフトウェア開発プロジェクトを悩ませる矛盾や矛盾を排除します。形式的な意味構造は、コードを1行作成する前に論理的な不一致を検出し、ビジネスルールを検証し、コンプライアンスを保証するための自動化された推論と推論能力を可能にします。さらに、グラフベースの表現により、システムを全面的に再編成することなく、変化する要件、市場状況、または規制の枠組みにすばやく適応でき、メンテナンスコストと技術負債を大幅に削減できます。

開発チームは、オントロジーが知識指導の役割を果たすことで、正確でコンテキストに富んだ情報を活用して、より正確で規制に準拠するローン処理システムを構築できます。開発者やビジネスステークホルダーが特定のユースケースやエッジシナリオについて質問すると、オントロジーは孤立した回答だけでなく、関連するすべての近隣データと共に完全なコンテキスト情報を提供し、意味と依存関係の完全な理解を可能にします。この包括的な知識ベースは、要件の誤解を大幅に削減し、ビジネスとITの間のドメインの整列を改善し、高価なリワークを排除し、開発サイクルを加速します。その結果、ビジネス意図をより忠実に実装し、変更に適応しやすく、さまざまな機能モジュールとユーザーインターフェイス全体で一貫性を維持するローン申請システムが誕生しました。

[図-3]オントロジーグラフ

2.4  アプリケーション設計

アプリケーション設計プロセスは、オントロジーを基本的なビジネスセマンティックモデルとして戦略的に使用することによって革新的に変化します。冗長性のないオントロジーの統合、構造化、同期化された情報アーキテクチャを活用すると、設計パスが驚くほど合理化されます。このオントロジー中心のアプローチは、ビジネスの意味を正確に把握するプラットフォームに依存しないモデルを提供し、AI設計エージェントが人の介入を最小限に抑えながら要件を解釈して実装できるようにします。 84のアーキテクチャ決定は、これらのAIエージェントのためのガードレールとガイダンスとして機能し、豊富なオントロジーモデルを機能的なソフトウェアコンポーネントに変換するために必要な制約とガイダンスを提供します。このフレームワークは、結果のアプリケーションが実装環境の技術的要件を解決しながら、意味論的な一貫性を維持することを保証します。

クラス図、ユースケース図、コンポーネント図、通信図、データベーススキーマ、状態遷移図などのUML成果物は、AIエージェントの処理を通じてオントロジーに直接表示されます。これは、人間のデザイナーがビジネス要件をこれらの技術的表現に手動で変換する従来の設計方法論におけるパラダイムの移行を意味する。 AIエージェントは、オントロジー関係、階層、ビジネスルールを体系的に分析し、元のビジネスモデルのトレーサビリティを維持する一貫したデザイン成果物を作成します。この自動化された変換は、ビジネスドメインの意味論的整合性を維持しながら、実装に必要な技術的特殊性を提供します。

アーキテクチャ決定は、オントロジーの概念をアプリケーションコンポーネントにマッピングする方法を定義し、サービスインターフェイスのパターンを設定し、状態管理アプローチを決定し、データ永続性戦略を指定するなど、AIエージェントの作業に重要なコンテキストを提供します。この決定は、オントロジーの豊富な意味論と実用的な実装問題を効果的に結び付け、AIエージェントが技術的に正確であるだけでなく、ビジネスに適した設計ソリューションを作成できるようにします。その結果、アプリケーション設計はビジネスアラインメントと技術的健全性という珍しいバランスをとり、AIベースの設計プロセスがオントロジーを活用して、すべての機能的および非機能的な要件を満たしながら、基本的なビジネスセマンティクスに忠実な洗練されたソフトウェアアーキテクチャを作成できるかどうかを示しています。

2.4.1  UMLベースの設計

UML図は、ローン申請システムの包括的な設計成果物を表し、システムアーキテクチャのさまざまな視点を提供します。このようなアーティファクトには、エンティティ関係を示すクラス図による構造的観点、トランザクションフローをキャプチャするシーケンス図による動作の観点、システム構成を説明するコンポーネント図が含まれます。これらの要因は、申請受付から承認ワークフロー、顧客管理まで、ローン処理領域全体にわたって明確な境界、相互作用、および責任を設定することで、実装を導く一貫した青写真を形成します。

これらのアーキテクチャアーティファクトは、システムの実装中に重要なガードレールとして機能し、開発努力全体の一貫性を確保しながら、ビジネスニーズに合わせて維持します。図は、ステークホルダー間で共有される語彙と理解を確立し、デザインパターンとアーキテクチャの制約を適用します。明確に定義されたインターフェイスとコンポーネントの関係を提供することで、実装のあいまいさを減らし、モジュラー開発を促進します。この構造化されたアプローチは、システムの整合性を維持しながら並列ワークストリームを可能にし、最終的に統合の問題を軽減しながら展開を高速化します。

AIエージェントは、人間のデザイナーの認知的偏見や矛盾なしに、ソフトウェアパターン、ドメインモデル、ベストプラクティスに関する膨大な知識を体系的に処理することで、これらのアーキテクチャアーティファクトを作成するのに優れた能力を発揮します。ニーズに応じて、多数の設計選択肢をすばやく評価して、完全な表記法の一貫性を備えた包括的な文書を作成できます。複数の図で矛盾を引き起こしたり、微妙な統合ポイントを見落としたりできる人間設計者とは異なり、AIエージェントはすべてのシステム側面を包括的に扱い、ビュー間の完全なトレーサビリティを維持します。さらに、AIで作成された設計は、アーキテクチャの原則、設計パターン、およびセキュリティ慣行の遵守を体系的に検証する組み込み品質監査の利点を活用して、進化するビジネス要件に耐えることができる、より強力でメンテナンス可能なシステムを構築できます。

2.4.1.1 クラス図


[図-4]設計 – クラス図

2.4.1.2 ユースケース図


[図-5]設計 – ユースケース図

2.4.1.3 コンポーネント図

[図-6]設計 – コンポーネント図

2.4.1.4 コミュニケーション図

[図-7]設計-コミュニケーション図

2.4.1.5 データベース・スキーマ

[図-8]設計-データベーススキーマ

2.4.1.6 状態遷移図

[図9]設計 – 状態遷移図

2.4.2  アーキテクチャ意思決定( Archtectural Decision )

[図10]設計 – アーキテクチャの決定

3.  開発結果

ローン申請システムは、レスポンシブフロントエンドアプリケーション、バックエンドサービス、リポジトリ層が明確に分離された3層アーキテクチャをうまく実装しました。フロントエンドは、ユーザーエクスペリエンスガイドラインに準拠した最新のレスポンシブWebフレームワークを使用して構築され、視覚的な一貫性を維持しながら複数のデバイスでアクセシビリティを確保します。フロントエンドチームは包括的な構文とセマンティック検証を優先的に実装し、ユーザーの旅の早い段階でエラーをキャッチし、ローン手続きを直感的に案内するためにビジネスワークフローロジックを含めました。 APIレイヤーは、フロントエンドコンポーネントとバックエンドコンポーネントの間で明確に定義された契約として機能し、両側が標準化されたインターフェースを介して明確なコミュニケーションチャネルを維持しながら独立して開発できるようにしました。

バックエンドサービスは、技術的な実装をビジネスドメインと一致させるために、ドメイン中心の設計原則を組み込んだSpring Bootを使用して開発されました。このアプローチは、ローン処理システムのさまざまな機能ドメイン間の境界を明確に定義し、ビジネスロジックをよりよく整理することを可能にしました。永続層は、最適化されたデータアクセスパターンを活用し、適切なトランザクション管理を通じてデータの整合性を保証しました。システム全体のアーキテクチャは、セキュリティ、スケーラビリティ、パフォーマンスなどの非機能的な要件を慎重に検討し、さまざまなローン申請負荷を処理するために適切なキャッシュ戦略と接続プーリングを実装しました。

実装フェーズでは、AIエージェントはそれぞれの専門的な役割に従って共同作業し、システムのさまざまなコンポーネントを提供しました。フロントエンドプログラマーは、レスポンシブデザインの原則に従って直感的なユーザーインターフェースを作成し、クライアントサイドの検証とワークフローガイドラインの実装に焦点を当てました。アプリケーションアーキテクトは全体的な構造を確立し、コンポーネントの境界と通信パターンを定義し、アプリケーションプログラマーはバックエンドサービスでコアビジネスロジックを実装しました。統合プログラマはシステム層間のシームレスな通信を保証し、データベース設計者はスキーマ構造とクエリパフォーマンスを最適化しました。このように専門化されたAIエージェント間の責任分担により、各コンポーネントが適切な専門性を確保することができました。

テストと品質保証は実施の過程で不可欠な要素でした。テストデータの生成AIは、検証に失敗したり、異常な処理経路を引き起こす可能性があるエッジケースを含む、さまざまなローン申請シナリオをカバーするさまざまなデータセットを作成しました。テスターAIは、要件の機能を体系的に検証し、ユニット、統合、およびエンドツーエンドのテストを実行して、システムがすべての層で正しく機能していることを確認しました。一方、品質監査人AIは、コード品質指標、パフォーマンスベンチマーク、セキュリティ慣行を検討し、システムが確立されたエンジニアリング標準とベストプラクティスに準拠していることを確認しました。この包括的なテストアプローチは、実装段階の早い段階で問題を特定して解決するのに役立ちました。

エンジニアリングワークフローは、明確なハンドオフ手順とコラボレーションメカニズムを構築し、これらのAIエージェントを効果的に調整しました。フロントエンドプログラマーがユーザーインターフェースコンポーネントを完成すると、統合プログラマーはAPI契約との互換性を検証し、テスターは要件に対する動作を検証します。アプリケーション・アーキテクトは定期的にアーキテクチャーをレビューし、実装決定がシステム設計全体と一致することを保証しました。この調整されたアプローチにより、プロのAIエージェントはプロジェクトの一貫した方向を維持しながら自分の専門知識を貢献することができました。その結果、高品質で強力なローン申請システムが提供され、AIベースのソフトウェアエンジニアリングは、調整された専門知識と厳格なプロセス規律によって複雑なビジネスアプリケーションを効果的に実装できることを示しました。

3.1  フロントアーキテクチャ

3.1.1  ユーザーエクスペリエンスフレームワーク

[図11]実装 – ユーザー体験フレームワーク

3.1.2  ユーザーインターフェース

[図12]実装 – ユーザーインターフェース

3.1.3  ユーザーインターフェースロジック

[図-13] 実装 – ユーザー インターフェイス バックエンド – Stub Api Driver

3.1.4  バックエンドインターフェース

[図14]実装 – バックエンドインタフェース

3.2  バックエンドアーキテクチャ

[図15]実装 – バックエンドアーキテクチャアーティファクト

3.2.1  アプリケーションプログラムインタフェース(API)

[図16]実装 – バックエンドAPI

3.2.2  データ転送オブジェクト(DTO)

[図17]実装 – バックエンドDTO

3.2.3  アプリケーションサービス

[図18]実装 – バックエンドアプリケーションサービス

3.2.4  ドメインサービス

[図18]実装 – バックエンドドメインサービス

3.2.5  リポジトリサービス

[図19]実装 – バックエンドリポジトリサービス

3.3   オントロジーセマンティッククエリと応答

今日の複雑なエンタープライズ環境で、ビジネスオントロジーとITオントロジーを単一の一貫したフレームワークに統合することは革新的な成果です。この統合知識リポジトリは、高レベルの戦略的目標から技術的実装の詳細まで包括的で権威のある情報ベースの組織の単一の真実ソースとして機能します。ビジネスコンセプトとその技術的表現の間に双方向のトレーサビリティを構築することで、組織は伝統的に戦略計画と実行を分離する情報サイロを排除することができます。これらの統合アプローチは、すべてのビジネス要件、プロセス定義、戦略的イニシアチブが対応する技術コンポーネントに直接接続され、企業全体で責任と理解を失うことのないチェーンを形成することを保証します。

この単一のデータソースの価値は、単純な技術的優雅さをはるかに超えています。以前は、複数のソースからの矛盾する情報を調整する必要があったクロスドメインの質問に一貫して信頼できる回答を提供することで、意思決定を根本的に変えました。経営陣が特定の技術実装が戦略的目標をどのようにサポートするかを問い合わせるとき、またはITチームがシステム変更のビジネスの影響を理解する必要がある場合、統合オントロジーは自然言語クエリを介して瞬時にコンテキストに合った洞察を提供します。これにより、情報の検索にかかる時間が大幅に短縮され、古いデータや矛盾するデータに基づいて行動するリスクがなくなり、すべての利害関係者がビジネスと技術の現実の両方を共有しながら運営できます。

ビジネスの俊敏性、つまり市場の変化に迅速かつ効果的に対応する能力は、組織が単一のデータソースに基づいて運用するときにはるかに高速になります。新しい機会や課題が発生すると、経営陣はビジネスと技術分野の両方でその影響を迅速に追跡し、影響を受けるプロセス、システム、依存関係を前例のない明確に把握できます。これらの可視性により、より迅速で自信を持って意思決定を下すことができ、組織は企業全体の影響の完全な理解に基づいて変更を実行できます。自然言語クエリ機能は、複雑な情報へのアクセスを民主化し、あらゆるレベルの利害関係者が専門的な技術知識なしに必要な特定の洞察を得ることを可能にすることによって、このプロセスをさらに加速します。

最も重要なのは、これらの統合オントロジーが継続的な革新と改善のための基盤を築くことです。ビジネス戦略が進化し、技術の実装が変化するにつれて、単一のソースも一緒に進化し、ビジネス意図と技術の実行の間の重要なつながりを維持します。この生きている知識ベースは、組織が変化している間に一般的に発生する制度的知識の損失を減らし、チームが同じ問題を繰り返し解決するのではなく、以前のタスクに基づいて構築できるようにします。このように包括的でアクセス可能な企業知識基盤を構築することで、組織は現在の運用を改善するだけでなく、対応力の向上、冗長性の減少、既存のビジネス-ITの境界を超えたより効果的なコラボレーションを通じて継続的な競争優位性を確保できます。

[図20]実装 – 統合知識ベースのエキスパートシステム

4.  回顧

オントロジーとAIエージェントベースのエンジニアリングを活用した実験的なプロジェクトは、エンタープライズアプリケーション開発の環境を革新することに大きな成功を収めました。このチームは、わずか3日という前例のない期間と150ドルという少ない予算で、フロントエンドアプリケーションからバックエンドデータベースインフラストラクチャまでの包括的なアパートローン申請システムを提供しました。これらの成果は、一般的に同様の結果を得るために数週間または数ヶ月かかり、はるかに予算が必要な既存の開発パラダイムに挑戦することです。このプロジェクトの成功指標は、企業レベルの基準を維持しながら、ビジネスの俊敏性、システム品質、画期的なコスト削減など、さまざまな点で明らかになっています。

[図21]設計段階における開発者とAIエージェントの役割

最も重要な成果は、ビジネス要件とIT運用を結ぶ単一のデータソースを構築したことです。オントロジーベースのアプローチは、ビジネスコンセプトと技術実装の間のシームレスな変換を可能にし、エンタープライズソフトウェアプロジェクトを悩ませる一般的な切断を排除しました。この一貫した知識ベースのおかげで、ビジネスアナリスト、デザイナー、開発者間のハンドオフの過程で発生する一般的な情報を失うことなく、システムアーキテクチャ全体でビジネスロジックを忠実に表現することができました。さらに、AIエージェントは、これらのオントロジーモデルをうまく解釈し、アーキテクチャのベストプラクティスに準拠しながらビジネスドメインを正確に反映する一貫した高品質のコードを生成しました。

[図22]実装、テスト、および実施段階の開発者とAIエージェントの役割

エンジニアリングアプローチの反復可能で一貫した特性は、もう一つの重要な成果です。従来の開発作業は、人の変数によって一貫性のない品質と予測不能なスケジュールで困難になることがよくあります。一方、このプロジェクトは、オントロジーモデルとエンジニアリングワークフローに従ってAIエージェントを適切に案内することで、予測可能な高品質の結果を導くことができることを示しました。この一貫性は、データモデルからユーザーインターフェイスまで、すべてのシステムコンポーネントに拡張され、不均一な要素のパッチワークではなく一貫した全体を作成しました。さらに、このアプローチは変化する要件に適応でき、アーキテクチャの整合性を維持しながら迅速な反復が可能になりました。

このプロジェクトで得られた最初の重要なレッスンは、エンジニアリングワークフローの重要性です。このプロジェクトは、AIエージェントが最適な結果をもたらすために構造化プロセスが必要であることを知りました。エージェントガイダンスへの一時的なアプローチは一貫性のない結果をもたらしましたが、明確な順序、依存関係、品質ゲートを備えた体系的なエンジニアリングワークフローは、一貫性と品質を劇的に改善しました。この構造化されたアプローチのおかげで、エージェントは孤立したコンポーネントを作成するのではなく、以前のタスクに基づいて適切なコンテキスト内で作業することができました。さらに、ワークフローは効果的なエラー検出と修正を容易にし、問題がシステムアーキテクチャ全体に広がるのを防ぎます。

このプロジェクトは、ドメイン固有の能力を持つ包括的なAIエージェントの必要性を強調しました。ユニバーサルAIツールはエンタープライズアーキテクチャの作業には適していないことがわかりましたが、特定のエンジニアリングパターンとアーキテクチャの原則について訓練されたエージェントは優れた結果を導きました。最も効果的なエージェントは、技術的な知識だけでなく、ビジネスドメインの概念の理解と各領域間の翻訳能力も示しました。この包括的な能力のおかげで、ビジネス目標と技術的制約を満たすことで、適切なトレードオフと設計決定を下すことができました。

アーキテクチャの決定は、システム全体の品質に影響を与える重要な要素として浮上しました。このプロジェクトは、AIエージェントが明確なガイダンスを与えれば、アーキテクチャパターンを効果的に実装することができますが、独立してアーキテクチャ決定を下す必要がある場合は困難を経験することを示しました。最も成功したアプローチは、人間のアーキテクトが主要なアーキテクチャの原則とパターンを確立し、AIエージェントがそれを実装全体に一貫して適用することでした。このような責任分担は、人間の戦略的思考を活用するとともに、AIの一貫性とディテールへの関心を活用して共生関係を構築することで優れたアーキテクチャ結果を生み出しました。

最後に、このプロジェクトにより、AIエージェントのトレーニングは既存のソフトウェア開発とは根本的に異なることがわかりました。最も生産的なアプローチは、単に規範的なガイダンスを提供するのではなく、エージェントにアーキテクチャ決定の「理由」を理解するように教育することでした。アーキテクチャの原則とドメインモデルの訓練を受けたエージェントは適切な実装について推論することができましたが、特定のガイドラインのみが提供されたエージェントは継続的なガイダンスを必要としました。これらの洞察は、今後のAI強化の開発は、より広範なコード生成能力ではなく、より深い概念理解を持つエージェントの構築に焦点を当てる必要があることを示しています。このタイプのエージェントトレーニングに投資することで、組織はこの実験プロジェクトで実証された驚くべき効率を維持しながら、高品質のエンタープライズソリューションを一貫して提供する持続可能な開発慣行を確立できます。


バイブコーディング(Vibe Coding)

AI Translation from Korean post
https://bmgovernance.com/category/%eb%b0%94%ec%9d%b4%eb%b8%8c-%ec%bd%94%eb%94%a9/

 1.バイブコーディングの背景

現在、ソフトウェア開発環境は急速に変化しています。開発者は単にコードを書くだけでなく、創造的で直感的な方法で問題を解決しなければならない状況に直面しています。このような文脈で「バイブコーディング」という新しい概念が登場しました。従来の開発手法は、厳密な計画と構造化されたアプローチを重視していましたが、急速に変化する技術トレンドとユーザーニーズにより、開発者はより柔軟で適応性のあるアプローチを必要としています。バイブコーディングはこのようなニーズから生まれた開発手法です。近年、開発者コミュニティでは、生産性と創造性のバランスを見つけることが重要なトピックとして浮上しています。多くの開発者がバーンアウトを経験し、コーディングに対する情熱を失っている状況で、バイブコーディングは、開発プロセス自体を楽しみながら効率的に作る方法として注目され始めました。

本プロジェクトでは、このような新しい方法の成熟度を体験し、実際の適用可能性を測るために、既存のミリオンドルソフトウェアの能力拡張のためのバイブコーディング方法を試してみました。

 2.本プロジェクトの開発部分(Dreamer)の紹介

目 的 :

将来の企業自律運営を可能にするための基盤となる企業のビジネスモデルのデジタル版であるデジタルツインのオントロジー情報を活用し、ビジネス実行を最新の人工知能技術に基づいて自律的に行うことができる運営システムを開発する。

目標 : 企業の自律運営 –

レベル 3(1stIteration)、高能力エージェントによるビジネス実行で業務運営担当者の介入を最小化。

  • ビジネス革新の自律実行
  • ビジネスソリューションの自律開発
  • ビジネスモデルの自律向上
  • ビジネスプロセスの自律実行
  • エンドツーエンドの要件管理の自動化及び IT 開発/運営の自動化

次の図で左側の部分は、既存のソフトウェアとして大型海外企業で使用しているビジネス革新及びモデリングプラットフォームとして、オントロジー基盤のデジタルツインを構築することを目指しています。そのシステムのオントロジー基盤のデジタルツインシステムには、企業の事業と業務処理に関するすべての内容がデジタルで定義されていれば、企業のビジネスに関するすべての要素間の関係と意味が明確に定義されています。詳細は http://www.bmgovernance.com 。で確認することができます右の部分が大胆にもバイブコーディングで試みた部分です。つまり、ビジネス実行ファクトリーは、企業のビジネスプロセスをエージェントロボットに実行させるもので、IT システムと連結してLLM にコンテキストを提供することができるMCP(Model Context Protocol)、企業の各部門の能力(Competency)をベクトル化して企業固有の知識を提供する専門家 RAG System、そして様々なLLM をLLM 毎の長所を生かしてエージェントが活用できるようにするLLM 統合モデル、Agent-to-Agent 協力を指揮する指揮部、そしてこのすべてを合わせて実際のビジネス価値を製造するプロセスエンジンで構成されました。

[図-1] 全体のプラットフォーム構成とバイブコーディング適用部分(黄色の領域)

クライアントは VS Code Extension を利用したアプリケーションです。クライアントをVS Code Extension にした理由は、IT 開発もワークフローに沿って開発する過程であるため、生成されたアプリケーションをVS Code IDE 環境で GitHub などと円滑に連携するためです。

[図-2] ビジネス能力活動モニタリング

実際、このように作成されたプログラムは十分にシステム規模で膨大なものでした。どう考えても最初の試みとしては無謀だと思われるかもしれません。資料調査と研究(要件の明確化)に1ヶ月、開発に 1 ヶ月、合計 2 ヶ月かかりました。もちろん、途中で何十回も諦めかけた困難と試行錯誤、そして失望、そして再び希望を発見する過程が繰り返されました。

[図-3] 統合エージェントモデルとビジネスオントロジー

本システムで定義し、実装した核心要素の一つは、高能力エージェントです。エージェントは専門的な役割を実体化したもので、基本的に必要な能力(Competency)を持っています。ここでの能力は、業務処理のための知識と処理手順を熟知し、強力な計画と推論能力を持ち、任務実行に必要な詳細な処理と必要なツールを巧みに扱うことができなければなりません。また、必要に応じて既存システムまたは外部システムとコンテキストを共有し、他のエージェントとリアルタイムの協業が可能でなければなりません。このような高コンピテンシーのエージェントは、業務の各専門家の役割を実体化(オントロジーに定義された役割の詳細プロファイルとペルソナが移植されて生成)することになります。このようなビジネス実行ファクトリーは、事業革新及びビジネスモデルがデジタル化された企業のデジタルツインのオントロジーを活用して直接実行するシステムとなり、このような能力を基に完全な仮想世界での企業運営が可能な運営システムとなります。つまり、企業の運営システムと考えてください。運営システムクライアントは、これをモニタリングして結果を確認するユーザーインターフェースと考えてください。実際に実行される様子は、Youtube で見ることができます(Business Capability Factory-Dreamer).

[図-4] エージェント知識基盤

また、本プロジェクトのアーキテクチャーで核心の一つは、エージェント知識ベースです。先に説明したように、高能力(Higher Competency)エージェントを生成するためには、多様なコンテキストと計画及び推論能力が必要です。このため、専門家用の知識言語モデルを自動的に構築することです。このような知識言語モデルの構築に必要なすべての情報は、ビジネス革新とモデルを持っているデジタルツインから知識パイプラインに沿って専門家用知識言語モデルに蓄積されます。金融機関の場合、約 100 余りの能力(Competency)部門別に定義されます。もちろん、選択によって 60~70 余りの能力(Capability)部門で定義することもできます。もう一つの軸は、企業のビジネス革新及びモデルオントロジーを基盤とした知識グラフです。ビジネスオントロジーは、内生的(Endogenous)に生成されるものと外生的(Exogenous)に拡張されるもので構文、意味、関係が定義され、時間の流れによって変化までを含んでいます。ビジネス的に見ると、価値定義、価値製造、価値伝達、価値獲得に関するすべてがグラフモデルで定義されているのです。真の企業の業務知識が重複することなく一貫してデジタル化されており、戦略から IT プログラムコードまで連携しています。このような環境では、業務処理は実体化され、待機中のエージェントに動的に割り当てられ、それぞれの仕事は業務アクションとツールによって実行され、必要に応じて現行システムの情報(モデルコンテキストサーバーを通じて)やコンテキスト的な決定または情報(LLM サーバーを通じて)が集約されて処理されます。本プロジェクト(バイブコーディング)では、以下のような技術基盤が使用されました。

サーバー環境

  • オペレーティングシステム : Mac OS,Apple M2-Max,12 Core, 64GB
  • プログラム言語 : Python
  • Agent-to-Agent Communication : G-RPC
  • 通信プロトコル : Web Socket
  • データベース : Vector DB(Chroma), Graph DB(MemGraph), Ontology DB(MongoDB)
  • 基盤アーキテクチャパターン : Event Driven Architecture
  • エージェント用LLM : OpenAI-4o, Anthropic-Claude and Opus, Google-Gemini, Ollama-Mistral
  • 開発ツール :Copilot やCursor を使用せず、Prompt だけを使用して開発する(意図は IT 開発を自動化するためには API だけを使用しなければならないので、その問題点、制約事項、そして解決策を見つけるためだった).
  • 開発用LLM Prompt サービスの使用割合:Anthropic-Claude(約 80%)、Opus(約 15%)、Google-Gemini(約 5%)。Opus を使用した理由は、Claude との品質差は微々たるものだが、1 日の使用頻度(特定の時間帯に入力できる最大プロンプト回数)をもう少し高くしてくれるので、価格対効果微々たるもの。Google-Gemini を使用した理由も同様。Claude のトークン制限(1 つのプロンプトで使用できる入力、出力を含む最大トークン数)のせいか、若干の違いしかない。一般的な開発であればClaude モデルで十分と思われる。

クライアント環境

  • オペレーティングシステム:VS Code が実行されるMac Os、Windows、Unix などのオペレーティングシステム。
  • プログラム言語 : HTML/CSS, Java Script, Type Script
  • 実行環境 : VS Code IDE extension(今後 Electron またはEclipse Theia も適用可能)

本プロジェクトを進行した開発者のビジネスオントロジーと技術基盤の知識程度

  • 本プロジェクトのサーバー技術基盤に対する経験 : ほとんどなし(Python 入門書を一度読んだ)
  • 本プロジェクトのクライアント技術基盤に対する経験 : 経験なし、技術知識なし。
  • ビジネスオントロジーシステムの知識 : 上級
  • アーキテクチャ思考レベル : 上級
  • メタ認知レベル : 上級
  • 問題解決レベル : 上級

それでは、具体的にバイブコーディングとは何なのかについて説明します。

## 3.バイブコーディングとは何か

1)Claude が説明するバイブコーディング

バイブコーディングは、開発者が自分の直感と感覚を信頼し、コーディングプロセスにおける「流れ(flow)」を重視する開発アプローチです。これは、単に技術的な能力だけを強調するのではなく、開発者の感情的な状態や創造的なエネルギーをコーディングプロセスに積極的に活用することを意味します。重要なのは、開発者が自分だけのリズムとスタイルを見つけ、コーディングすることです。まるで音楽家が即興演奏をするように、開発者もコードを作成しながら、自然な流れに沿って創造的な解決策を見つけることがバイブコーディングの本質です。これは、従来の体系的で分析的なアプローチとは異なる、より有機的で直感的な開発方法です。

Vibe Coding はまた、開発環境とツールのパーソナライゼーションを重視し、各開発者が最も快適で生産的だと感じる環境を構築し、その中で独自のコーディングスタイルを発展させていくことを推奨しています。これは、単にコードを書くだけでなく、開発という行為そのものを芸術的な表現として捉えるという考え方です。

2)Gemini が説明するバイブコーディング

バイブコーディング(vibe coding)」とは、開発者コミュニティで使われる新語で、文字通り「雰囲気」や「感じ」を意味する「vibe(vibe)」と「coding(coding)」を組み合わせた言葉です。これは、厳密で詳細な事前計画や定立された理論に従ってコードを書くのではなく、開発者の「勘」、つまり直感や経験に大きく依存してプログラミングするスタイルを意味します。まるでジャズ演奏家が楽譜なしで即興演奏をするように、問題の全体的な流れを感じながら、解決策が思い浮かぶままに自然にコードを解いていく方法を指します。この用語は、使う人の経歴や状況によって、ポジティブな意味とネガティブな意味の両面を持ちます。例えば、いわゆる「古参」と呼ばれる熟練したシニア開発者のバイブコーディングは、数多くの経験から蓄積された深い洞察力の現れと考えられています。彼らの直感は、迅速かつ効率的な問題解決能力に映し出され、賞賛の対象となることもあります。一方、経験の浅いジュニア開発者が計画なしにコードを作成する場合、これは体系が不足してメンテナンスが難しい「スパゲッティコード」や技術的な負債を引き起こす原因として指摘され、ネガティブなニュアンスで使用されます。

バイブコーディングは特に成果物のスピードが重要視される環境でよく見られます。代表的に、迅速なプロトタイプ製作が必要なスタートアップ、韓国特有の「早く早く」文化の中で迅速に機能を実装する必要がある場合、またはコラボレーションの負担が少ない個人プロジェクトでよく見られます。また、フロントエンド開発者が決まった数値なしに UI を微調整して「感覚的な感じ」でデザインを完成させたり、熟練した開発者が複雑なバグの原因を直感的に把握して解決する際に、バイブコーディングの真価が発揮されることもあります。結局、バイブコーディングの成否を左右するのは開発者の経験です。ジュニア開発者の「バイブ」が根拠のない推測に近いものであるのに対し、シニア開発者の「バイブ」は、数千、数万時間、様々な問題を解決して脳に刻まれたパターン認識の結果です。したがって、一見、同じように即興でコードを書いているように見えても、その結果物の安定性、拡張性、そして品質は開発者の内공によって顕著な差を見せます。

要するに、’バイブコーディング’は、ソフトウェア開発が単に硬い論理と工学的な手順だけで行われるのではなく、時には創造性と芸術的な感覚が要求される複合的な活動であることを示すユーモラスでありながら現実的な用語です。これは、体系的な開発方法論の重要性と一緒に、長年の経験から生まれる開発者の直感的な洞察力も価値ある能力であることを認める現代開発者文化の一端をよく示しています。

2)本プロジェクトの開発者が説明するバイブコーディング(経験的)

本プロジェクトの開発者が説明しようとするバイブコーディングは、伝統的な開発方式、つまり、ウォーターフォール的な方法論に従うか、アジャイル方式に従うか、分析、設計、コーディング、テストという決められた方法論ベースの成果物(Artefact)を基に、開発者の経験と技術基盤に対する知識レベルに応じて開発すること(いわゆる、How 中心)ではなく、開発しようとする対象の必要性(Why)とその必要性に焦点を当てたソフトウェアが備えるべき能力(What)に集中し、それを達成する方法(How)は AI、すなわちLLM を活用して対話的に開発していく方法だと定義します。

本プロジェクトにおける強力な必要性は、未来予測技法を通じた企業の競争力確保方案でした。その内容は、近い将来は、期待するかしないかにかかわらず、AI とロボットを利用して企業の競争力確保が重要だということです。したがって、企業がビジネスを営む方法であるビジネスプロセス(業務活動)を強力な AI と実行ロボット(エージェント)を活用してプロセス能力を高め、その結果、企業の競争力が確保できるシステムを開発するということです。また、メタ認知的な観点からこのようなアプローチが証明されれば、企業のビジネスモデル革新も自律的にエージェントによって可能になるということです。

このような必要性(Why)に基づき、システムの必要能力(What)を定義し、開発しました。そのため、先ほど説明したように、本プロジェクトを進めた開発者は、開発および運営環境の基盤技術に対する知識がなかったり、不足していたにもかかわらず、目標を達成することができました。もちろん、この過程が楽だったとは言えません。初めての試みであったため、難しかったし、また、LLM の幻覚現象(Hallucination)のため、何度も繰り返す困難を経験することもありました。その試行錯誤の過程で多くのことを経験することができ、今後、ソフトウェア産業で何を重視すべきか、教育はどうすべきかなどを学ぶことができました。

## 4.バイブコーディングの特徴

1)AI と対話型で開発

バイブコーディングは、AI と対話型で開発する方法です。要件をプロンプトディレクティブで作成し、これをLLM サービスを通じて伝達し、所望の結果を得る方法を指します。そのため、プロンプト(コンテキスト+

ディレクティブ)の作成が非常に重要です。もし、プロンプトの内容が不十分だったり、一貫性がなければ、生成された著作物の品質も低くなります。つまり、良質の入力があれば、良質の結果物を得ることができます。一貫性に欠けるプロンプトは大きな問題を引き起こします。つまり、最初は小さな違いですが、開発が進み、深度が深まると大きな違いをもたらすことになり、最悪の場合、コード全体を捨てて、最初からやり直さなければならない場合が発生します。

2)公式に決められたArtefact がない

Vibe コーディングの基本入力にまだ決まった標準またはArtefact がありません。もちろん、モデルを提供すれば、より質の高い著作物を得ることができます。つまり、UML のようなモデリングに慣れている開発者であれば、これを積極的に活用する必要があります。もし、プロンプトだけで開発をするのであれば、プロンプトを構造的に作成する方法を事前に習得することをお勧めします。 今後、状況が許せば、この部分だけを整理してみるつもりです。

3)反復的、段階的な開発

いくら完全な AI と言っても、アプリケーションを一度に開発することはできません。反復的、段階的に開発することが基本になります。そのため、反復的、段階的に開発する方法に慣れている開発者は、より簡単に開発することができます。もちろん、反復的な段階的な方法がメリットばかりがあるわけではありませんが、アーキテクチャ思考とリファクタリングの概念がしっかりしている開発者であれば、より簡単に開発することができます。

4)プロトタイピングを基本に始める

先ほど説明したように、バイブコーディングのコンセプトはインタラクティブに開発することであり、プロトタイピングのようにモックアップ(Mock-up)を作って(そうしたくなくてもそうなってしまいます)、これを詳細化する方法で主に行われます。言い換えれば、最初は軽く始めて(Mock-up)、モックアップの完成度に感心して、まるでアプリケーションが開発されたような気がして、もう少しだけ追加すればいいだろうという風になります。もちろん、この過程でコントロールをうまくすれば、アプリケーションが早く完成することができます。

5)Why、What が重要で、How は AI にとって重要です。

AI は Why(目標)と What(必要内容)が明確であれば、完全なコード(Clean Code)をすぐに生成することができます。技術基盤に対する高度な知識がなくても開発することができます。本プロジェクトでは、開発者が技術基盤の知識がほとんどなくても開発することができました。これからは、How を思い切って AI に生成させ、Why とWhat に集中する必要があります。ただし、ここで言うHow について理解を明確にする必要があります。ボープロジェクトで経験したところ、How には 2 種類あります。一つ目は、既存の誰かがすでにやった、または知られている How です。もう一つは、まだ知られていない新しい方法です。前者の場合は、思い切って AI に任せます。しかし、後者の場合はまだ開発者の手に委ねられています。

## 5.開発者がヴァイブコーディングを活用する方法

開発者がバイブコーディングを実務に適用するためには、まず何をすべきか(つまり、何を開発すべきか)を理解することが非常に重要です。バイブコーディングはLLM、つまり AI と一緒にプロジェトを進めることです。 LLM は How については本当に早い時間内に成果物を見せてくれます。つまり、単純なコーディングでは開発者が AI と競争することはできません。開発者がすべきことはメタ認知です。目の前の直面した問題にとらわれず、より根本的な問題を理解しようとするとき、AI は素晴らしいツールとして使うことができます。根本的な問題とは何でしょうか?これは、デザインシンキングワークショップで、またはシックスシグマワークショップで行ったような 「なぜ(Why)」という質問を通じて根本的な必要性と伝達すべき価値を理解することです。次に、その価値を伝達するための能力をシステム思考またはアーキテクチャ的な思考を通じて構造的に理解し、MECE(mutually Exclusive, Completely Exhausted)技法で完全性を検証し、これを段階的に繰り返し適用することです。

ここで、段階的に繰り返し適用するということは、上位レベルから下位レベルに繰り返し適用することを意味します。What とHow の関係はレベルの違いです。つまり、あるレベル(レベル)で下位レベルは常にHow を表します。全体的に完成された構造の観点から見ると、What-How はまるで親と子のように世代を超えて繰り返し現れるようなものです。これを理解すれば、バイブコーディングの核心を理解したと私は敢えて言うことができます。あとはプロンプトの作成です。理解したプロジェクト目標をLLM に学習させ(最大 10 文で十分で、ほとんどの場合 4~5 文で動作します)、What を指示文(Prompt)で伝えれば、How は満足に生成されます。ここで理解すべき重要なことは、HOW はWhy とWhat によっていくらでも違って生成されるということです。また、今日現在(2025.6.3)までのLLM 技術(Anthropic Claude Opus4, Google Gemini Pro など)は、本プロジェクト規模のコンテキストをLLM が十分に管理できないということです。そのため、開発者が先に説明した内容を少なくとも頭の中または別のノートに記録し続けなければならないということです。後述しますが、まだこのような規模のコンテキストを一貫して維持できない理由は、LLM 自体の問題というよりは、商業的にサービスを提供するために設定された様々な制約のためだと推測されます。

## 6.バイブコーディングの経験談

実は最初からこのような大きなシステムを構築することを考えていたわけではありません。最初はビジネス革新とビジネスモデリングプラットフォームにビジネスソリューション開発のためのS olution Factory を計画しました。このような機能はJava コーディングででき、開発者のための知識をまとめて資料を伝達する方式ですつまり、顧客の生涯価値を予測するテーマであれば、LLM とオントロジーを活用して必要な資料を確保し、データマイニングまたは機械学習ソリューションを開発して提供する方式です。この程度はChain-Of-Though またはTree-Of-Though 程度で可能でした。このような経験を通じて、ビジネスプロセスの全過程を最新の AI 技術、例えば、LLM、MCP、AGENT、RAG などを活用してビジネスプロセス能力を革新し、自動化することができるだろうというアイデアが導き出されました。このような背景には、能力カプセル(画期的な方式の企業能力確保案、特許登録)というアイデアを適用してみようという欲望も作用しました。詳しくは、本資料の末尾にあるサイトを訪問するか、または概念的な内容はGartner 2022 新技術動向の一つであるPackaged Business Capability を参照してください。このような考えのもと、やや無理のあるプロジェクトに着手することになりました。

最初のスタートは良かったです。数文の背景説明と目標、価値、必要能力などを説明するプロンプトで感心するようなコードが生成されました。先に説明したように、本プロジェクトで本プロジェクトで技術基盤の経験と知識がない開発者として私が直接経験したところ、びっくりするような成果物だったのです。特に、私は基盤技術の知識がないため、敢えて手が出せなかったコードが溢れ出てきて、それらを指示通りに設定して最初のテストをした時はまさに魔法でした。あっという間にほとんどの機能が作成され、テストされるのを見て、2~3 日で開発が完了するように感じました。

しかし、”悪魔は細部に宿る”という言葉通り、突発的な現象が発生し始めます。その経験を下の図に表示してみました。つまり、感嘆の段階、失望の段階、そして怒りの段階などです。

[図-5】バイブコーディングのJourney とその段階たち

最初の経験は(1)のカーブに沿って進みました。わずか数日で 90%以上のコードが完成しました。本当に感嘆の段階にあったわけですが、この期間には本当に AI が人間よりも信頼できるようになります。まさに数文でコードが生成され、実行可能な、欠陥のないコードが出てくるので、そうではないでしょうか? しかし、ある瞬間から Token Limit に引っかかり始めます。正確ではありませんが、コードラインで見ると 1,000 ラインくらいからLimit が問題になり始めます。これは、1,000 ラインくらいで何回か会話をしていると、TokenLimit に引っかかったので、セッションを再開するように応答が出ます。Token Limit に引っかかると、再度セッションを開始しなければならないのですが、この場合、今まで会話していたコンテキストを失ってしまいます。何個か修正したのにまたLimit に引っかかったと出ます。これを一日中繰り返します。突然、仕事をさせすぎたので何時までは利用できないというメッセージが表示されます。いや、コーディングを後ろで人がやったのか?なぜ休憩時間を与えなければならないのか。徐々に失望段階に入ります。LLM 提供会社のサブスクリプションのグレードを調べます。高価なグレードに上がると上限が増えると書いてあります。そうか、それならそうするしかない。 お金を惜しまず最上級にグレードアップします。やはり良くなったようです。 しかし、すぐに失望してしまいます。若干の違いがあるだけで、現象は似ています。諦めようか、やっぱり「機械が開発するのはまだ無理だ」と諦めようと思いつつ、今まで費やした時間がもったいないので再挑戦してみます。しかし、時間が経つにつれ、今度はもっと大きな問題が発生し始めます。あまりにも多くの再試行でコード間の一貫性が落ちる現象が現れ、たまに幻覚現象(Hallucination)が現れます。コード生成をしたのに間違った理解をして間違ったコードが生成されます。既存のコードを欠落させてしまいます。品質がどんどん落ちます。怒りの段階に入りました。いや、今まで信じてきたのに、これが意味があるのでしょうか。今、LLM が自分が生成したコードが正しいと自爆します。実際に’Perfect’ロジックだと生成が終わる部分に自信を持って主張するメッセージを一緒に出力します。ところが、コンパイルすると 140 個のエラーが出ます。腹が立ちます。他のコードと一貫性を失ってしまいました。 なぜコードが合わないのかと質問すると、忘れてしまったと巧妙に話します。何回か感情的な会話が続くと、今までプログラム単位別または機能別に生成していたのに、突然私に修正しろとコードの一部だけを出力してくれます。何行目を修正すればいいと言ってコードを渡しますが、行番号が合わなくなり始めます。コンパイルエラーを出して修正しろと言ったら、私が修正を間違えたからだと文句を言います。こんなこと、…人間なら解雇でもしたかったです。これ以上コード品質が向上しないので、最後のチェックポイントバージョンに戻ります。2~3 日を無駄にしました。虚脱です。

さて、どうすればカーブを変えられるでしょうか?少なくとも(2)番のカーブを維持するか、または望ましい (3)番のカーブを作ることができるでしょうか?はい、ついに (3)番のカーブを見つけました。 ある程度の失望段階は今は避けられないと思います。しかし、品質 100%、つまり希望する能力を持ってプロジェクトを終了することは可能です。その秘訣は、これから人が開発する方法から時間配分を変え、何を集中すべきかを明確にし、AI と仕事をする方法を学ぶことです。

## 7.第 3 のカーブJourney は可能か?

私がJourney という言葉を使う理由は、単純な旅行(軽い気持ちで景色を楽しむ)ではなく、目的地に行くために計画を立て、困難に立ち向かい、解決し、一歩一歩進み、場合によっては再び中間地点に戻って迂回することもあり、最終的に目的地に着いたように見えても、それが終わりではなく、別のステップの始まりになるからです。番目のカーブと 3 番目のカーブの違いは、2 番目のカーブでは希望する品質レベルに達しないまま、プログラムの改善だけを続けることですが、3 番目のカーブでは、ある時点で希望する品質レベルを得て、その能力を備えたプログラムに仕上げることができるということです。

1)システム的思考

システム的思考は、あるシステム(最終目的物)を考える時、全体と部分を考えることです。これは認識論で非常に重要な概念であり、問題解決方法の始まりと言えます。次の図に示すように、一つの目的は、左側の小さな円はその下位構成要素で成り立っています。だからといって、下位要素だけで上位要素を満たすとは言えません。つまり、上位要素は常にEmergent Property(創発性特性)が追加されるからです。したがって、上位要素を下位要素に分解し、上位要素が持つべき創発性特性を理解しなければなりません。つまり、自動車がエンジン、シャーシ、ハンドル、ダッシュボード、ドア、椅子、燃料タンクなどで構成されますが、これらを全部持っているだけでは自動車とは言えません。したがって、どのように構成した時、それが自動車になることができるかを把握し、それらの構成要素にこれを合算して自動車が作られるのと同じです。 “Systems Thinking:Managing Chaos and Complexity”、Jamshid Gharajedaghixity、はシステム思考をするのに役立つでしょう。

[図-6] 第三のカーブJourney のためのアーキテクチュラル思考

2)アーキテクチャ的思考

アーキテクチャ思考で説明したいことは 2 つあります。一つはリファクタリング(Refactoring)で、もう一つは Cross Cutting についてです。全てのシステムは進行したり、時間が経つにつれてエントロピーが増加し、変則的な状況が多くなります。このような状況を解決する方法の一つは、プログラミングではリファクタリングだと思います。つまり、上の図で(1)の段階では、下位要素間の境界がはっきりしているようです。ところが、段階が深くなるにつれて、各分岐(Branch)間の重複度が増えていきます。私が経験したところでは、このような現象が発生し始めると、LLM が生成するコードの品質が急速に低下します。また、この時から幻覚現象(Hallucination)が増加します。このような点に入る前に、このようなリスクをモニタリングしなければなりません。また、このような現象が認識されるとすぐに、図(2)のように範囲を確定して、(3)の方向にリファクタリングをしなければなりません。リファクタリングの基準は機能強度(Functional Cohesiveness)と低い結合度(Loosely Coupling)です。ここでまた、What に直面することになります。LLM にリファクタリングを指示することはできますが、What が明確でなければ、すぐに同じ問題に直面することになります。リファクタリングの基準は Cross Cutting の観点です。本プロジェクトの初期に苦労したことの一つは、リファクタリングを軽く考え、D epth First、つまり、それぞれの機能を深いレベルまで深く考えずに作成したことです。リファクタリングをする時、どのような視点が望ましいのかについて十分な検討が必要です。市場には多くのアーキテクチャーデザインパターンに関する本があるので、少なくとも一冊以上のアーキテクチャーデザインパターンの本を読むと多くの助けになると思います。

3).文脈的思考

HOW を表すサブ要素は Why(目的), What(能力)の定義によって変わることがあります。もう一度考えてみると、下位要素も「下位要素の下位要素」の立場で見るとWhat です。つまり、How(下位要素)が間違って生成されると、それ以下はすべて間違ってしまいます。したがって、(4)の範囲のように、常に文脈的思考と一貫性を保ちながら AI と一緒に作業する必要があります。AI は瞬時にHow を生成してくれますが、文脈的な一貫性を維持することには限界があります 。生成されたコードを文脈的な観点から検討することを欠かすと、あっという間に別の道に入り、第 2カーブまたは第 1 カーブのJourney を経験することになります。また、文脈(Context)に対する明確な理解が必要です。Context Free(Context Free)、Context Aware(Context Aware)、Context Injection(Context Injection)、Context Based(Context Based)をよく理解し、維持しなければなりません。抽象化と具体化も適切に使用しなければなりません。LLM は基本的に誰かのコードから学習した内容を基に、ユーザー(つまり、開発者)の文脈的思考に基づいてコードを生成します。したがって、開発者が文脈的思考が不足している場合、結果物はそのレベルで生成されます。しかし、開発者が文脈的思考をしていて、これを利用して少しのナッジ(Nudge)をするだけで、結果文のレベルは大きく変わることをたくさん経験しました。世界 100 大工学者の一人であるパク・チャンギュ教授が書いた”コンテンツが王なら、コンテキストは神だ”という本のタイトルが実感できます。という本のタイトルが実感できます。

4)言語に対する理解

LLM はLarge Language Model、つまり巨大な言語モデルです。言語に対する理解があれば、LLM を効果的に使用して、より質の高い答えを生成することができます。つまり、動詞、名詞、形容詞、副詞などを使用して文章を作成することになりますが、名詞はWhat を、動詞は期待値を表すものとして使用しました。可能な限り形容詞と副詞は使用を避け、それに該当する参考資料または数字で明示しました。名詞については、使用に一貫性を保つことが重要です。もちろん、類似性によって同じ意味で把握して成果物を生成しますが、時には一貫性の欠如で、開発段階がず いぶん進んだ後、別の話をしていると思われる時があり、バックアップしておいた時点に戻る場合が予想外に多かったです。つまり、微妙な角度の違いが段階が進むにつれて大きな弧を描くようになったのです。動詞については、開発者が望む期待値に応じて適切な動詞を見つけ、自分なりの標準のように使用することをお勧めします。本プロジェクトのシステムでは、約 60 個の動詞を分類し、分類された動詞のグループを代表する動詞を選定し、それに応じた質問パターンを整理してエージェントに組み込んで使用しています。そうした理由は、批判的思考の観点から、動詞に応じた期待値の表現であるため、より高い生成物を得るために、様々な追加質問を Agent ができるようにしています。同じように、私自身が AI と作業する際にも同様の方法で行いました。もし、文脈的質問に慣れていない方は、”A More Beautiful Question: The Power of Inquiry to Spark Breakthrough Ideas”、Warren Beger を一度読んでみることをお勧めします。

## 8.バイブコーディングで得た教訓

Vibe コーディングを実践して得た最も重要な教訓は、「開発は単純な技術作業ではなく、創造的な活動である」ということです。コードは単に機能を実装するツールではなく、開発者の思考と創造性を表現する媒体になることを実感します。また、バイブコーディングをしながら、試行錯誤を避けることができないこともわかります。LLM が生成した生成物は、ほとんどがHOW に該当する下位要素です。そのような下位要素がなければ、上位要素を作ることはできません。だからといって、部品が全て揃っているからといって上位要素になるわけではありません。そこには、開発者の創発性(Emergent Property)が加わる必要があります。本プロジェクトを進めながら感じたことは、基本的なレベルは AI がやってくれますが、ある程度のアプリケーションからは開発者のレベルに合う程度の生成物が作られるということです。さらに、バイブコーディングプロジェクトを進めながら、実際に何百回の失敗の末に学んだこと(?)は次のとおりです。 私の勤務時間は朝 8 時から夜 9 時まででした。その間に食事時間約 1 時間(昼食、夕食)、そして 2~3 時間程度の運動時間があります。

1)定期的なバックアップと設計定式化

前にも何度も説明したように、ほとんどのアプリケーション開発過程では、感嘆の段階で最終生成物を得るのは難しいと思います。二つ以上の機能を生成して何回か修正すると、すぐに落胆の段階を経験することになります。この時、最後にバックアップしたチェックポイントにロールバックする必要があります。もし、バックアップがない場合は失敗です。その判断をよくしなければなりませんが、たまにどうにか修正してやってみようかと思って怒りの段階 に入る場合が思ったより多かったです。私の経験では、ロールバックが失望と怒りの段階を減らす方法でした。そのため、能力または機能が一つずつ完成するたびにバックアップをすることを基本にしました。バックアップには物理的なコードバックアップと設計バックアップがあります。物理的なバックアップは完成されたコードをバックアップすることであり、設計バックアップはプロンプトをバックアップすることです。 ここでコードバックアップより重要なのは設計バックアップです。なぜなら、コードはHow と説明しましたが、このような How はWhy やWhat が変わればすぐに役に立たなくなります。 そうすると、今までやったすべての作業の結果が役に立たなくなります。しかし、Why とWhat を定義して指示したプロンプトが正確に最後のバージョンで維持されていれば、Why とWhat が変更されたとしても簡単に修正、How を修正することができ、変更に対する修正が非常に早く進めることができます。

2)明確化

開発者はプロンプトを作成して AI に伝達し、プロンプトの要件を AI が解釈してコードを生成する方法でアプリケーションを開発することになります。しかし、要件を正確に伝達する方法は容易ではありません。その理由は、開発者が作成した要件にも一貫性が欠けていたり、または不完全な場合が多々あります。このような場合、生成されたコードは当然のことながら、期待とはかけ離れたものになり、既存の完成していたアプリケーションが最初のカーブのJourney に行くことになります。本プロジェクトを進めながら、このような問題を解決するために、可能なモデルに基づいたプロンプト、つまり指示事項を伝達しようとしました。それにもかかわらず、頻繁に不完全な要件によって基本コードが汚染される状況が発生しました。第 3 のカーブを維持するために使用した方法は、要件を定義し、コードを生成するように指示するのではなく、AI に理解したことを説明し、不足している要件を伝え、承認があるときにコードを生成するように誘導しました。そうすることで、怒りの回数が著しく減少し、失望の段階の経験も低くなり始めました。

3)完全なコードセット

AI も記憶には限界があります。つまり、LLM はすべての会話を記憶することができますが、サービス商用化の過程でリソースの効率的な利用のために限界が適用されたような印象を受けました。特に、問題が発見されたり、一部の機能向上のための要件を伝えると、それに対応するコードを生産することになります。ところが、このコードが完全なセットでない場合がよくあります。もし、開発者が注意を払わないと、すぐに最初のカーブJourney に入ることになります。その理由は、問題のあるコードまたは新機能に集中して類似性分析に基づいて生成が行われるため、機能向上またはエラー解決に関与していなかった正常なコードが消えてしまう場合が発生することです。ある意味、リソースを効率的に使うためのものでもありますが、開発者の立場では少しだけ注意しないとコードが修正されてしまい、裏付けがなければすぐに怒りの段階に突入してしまいます。本プロジェクトでは初期に何度もこのような状況を経験し、その後は新しいコードが生成されると必ず総コードライン数を比較しました。もし、コードライン数が著しく異なる場合は、すぐに質問をして、その理由が何なのかを把握しました。 このような質問のたびに AI が答えるのは、「I am sorry」でした。このような場合、どうすればいいのでしょうか?私がやったのは「完全なコードセットを作成する」というディレクティブでした。しかし、このディレクティブを入力したのに、トークン制限に引っかかってしまったらどうすればいいのでしょうか?仕方ありません、セッションを再開してコンテキストを再設定する必要があります。 ここで重要なのは、どのようにコンテキストを維持することができるかということです。様々な方法で既存のコンテキストを連携させようとしましたが、公式的な答えは前のセッションのコンテキストを知らないということです。(しかし、コンテキストを再設定するためにしばらく入力して会話していると、コンテキストを知らないというのは公式的なもので、知っているような気がすることがよくあります)。皆さんもやってみてください。コンテキストが分からないので再設定してくださいと言われます。本当に怒りがこみ上げてきます。さて、どうしますか?開発がだいぶ進んだので、最初から会話していたものをすべて再入力すると、2、3 回目の会話でまたトークン制限に引っかかります。そうなるとまたセッションを開かなければなりません。泣きたくなります。どのようにこの難関を突破するのでしょうか?アプリケーションがある程度大きくなると、完全なコンテキストを再入力することは不可能です。ここで再びアーキテクチャ思考が必要なポイントです。[図-6]で該当ノードを基準に上位ノードに集中します。そして、リファクタリングしたコードセット(プログラム)だけを対象にコンテキストを入力します。そのコンテキストを入力する必要もありません。一度、図(4)のように範囲を設定してプログラムをUpload すると、コンテキストの更新が行われます。その理由は、そのプログラムが要件を最も完全に説明しているからです。さて、今、制御可能な段階に入ったようです。しかし、リファクタリングがうまくいかなかったら、これさえも難しいです。なぜなら、Upload しなければならない範囲の総コード数が大きくなり、これはまた、別のトークン制限に直接影響を与えて、最初のカーブのJourney をたどることになります。

4)適切な視点の提示

本プロジェクトを進めながら、プロンプトの言葉(ディレクティブ入力)として AI と一緒にコードを生成する方式は非常に新しい方式であり、驚くべき経験を経験します。しかし、ある程度慣れてくると、生成されたコードと説明を見ると、コードを生成するのですが、誰かのコードを取り込んでいるような気がします。つまり、ロジックと設計がすでに誰かがやったことを本プロジェクトに合わせて変更することを感じます。もちろん、当然の結果ですが、少し他人の足を引っ掻くような感じを受けることがあります。このような感覚は、同じWhat でも期待と違うときに感じます。このような時は、視点を明確にする必要があります。その視点には様々なものがあります。抽象化レベル、ソフトウェアライフサイクル、ステークホルダーの価値観(例えば、テスト担当者の視点)、アーキテクチャなどを考慮して、視点を指示文に含めて入力します。

5)ヒントやナッジ

LLM は単語とコンテキストの類似性によって生成される内容が変わります。大部分は、ディレクティブのように入力されたコンテキスト、そしてセッションが進行された獲得されたコンテキストを通じて生成物の適切性が決定されます。それにもかかわらず、場合によっては、コンテキストやディレクティブに含めるのが難しい具体的な要件を伝達するためには、ヒントやナッジを使用すると、時間と品質を大幅に改善する場合があります。特に、ユーザー利便性または画面の審美性(aesthetic)に関連する要件であれば、特にそうです。このような場合は、希望する画面の事例を画像で提供したり、すでによく知られている事例をヒントとして与えると、すぐに希望するものを得ることができます。本プロジェクトの場合、アプリケーションがVS Code でプラグインの形で動作するため、頻繁にVS Code 標準をヒントまたはナッジとして使用しました。バックエンドプログラムを生成する時にも、このようなヒントやナッジを使うことで大きな効果を見たことが多いです。

もちろん、このようなヒントやナッジは先ほど説明した考え方に基づいて多様に活用することができます。場合によっては、コードを生成してテストをしても似たようなエラーが繰り返されることがあります。このような時、従業員がエラーを繰り返す時に指示したように「コードを徹底的に検討して」とい う文言を入れて指示文を入れると、すぐに気づいて反応が来ます。

6)過度の信頼は避ける

本プロジェクトを進めながら感じたことは、AI と対話形式で要件を指示して、その結果をレビューしてテストしていくと、不思議と立場が変わっていく感じがします。最初は開発者が主導している感覚で会話をするのですが、次第に設計や開発は AI が行うようになり、開発者はテスターになっていくのを感じるようになり、現実的にそうなってしまいます。例えば、最初の会話は「画面を作成してくれ」と指示して画面関連のコードが生成されます。 そうすると、テストは主に人が行うことになります。しかし、改善事項やエラーがあり、再度指示すると、その次からは AI が設計者、開発者であり、人間開発者は AI の指示に従ってテストし、テスト結果を報告し、AI の指示に従ってログを確認し、設定をすることが多々あります。システムユースケース」が「ヒューマンユースケース」に変わる時点です。その次からは、AI が生成して指示する内容がうまくいかない時は徐々にイライラし始めます。まるで、AI は絶対にエラーがないような信頼に基づいて過度に頼る習慣が形成されるようです。今日現在まではまだその程度の信頼をしてはいけません。過度な信頼をすると、最初のカーブJourney に行く可能性が非常に高いです。常に批判的思考を維持し、AI が生成したコードにもエラーがあるという点を看過してはいけません。特に、リファクタリングがうまくいかないときは、人が開発するときに経験する問題をそのまま踏襲します。

## 9.バイブコーディングの陰影

バイブコーディングのメリットは詳しく説明する必要はないでしょう。あまりに明白すぎるとも言えます。しかし、バイブコーディングにも影があります。最大のリスクは「自己合理化の罠」です。単に怠惰や無計画をバイブコーディングと言いくるめる場合があります。真のバイブコーディングは、自由さの中でも目標と品質を失わないことが重要です。バイブコーディングをすると、全体像を無視したまま、すぐにコーディングに入る場合が多いでしょう。なぜなら、プロンプトにいくつかの要件と指示文を入力しただけなのに、幻想的にコードが作成され(多くのユーチューブで言うように)、まるでアプリケーション開発が完了したように錯覚させます。つまり、感嘆の段階に入ったのです。 このような誘惑を振り払うのは難しいでしょう。このようなアプローチは、失望の段階を経て、怒りの段階に行く近道です。また、「正常にアプリケーションを開発した」としても、開発者はアプリケーションコードに対する知識が不足することになります。つまり、自分で開発したコードを修正するときと、他の人が開発したコードを修正するときの危険性が異なるのと同じです。これを回避する方法は、アーキテクチャに対する理解を深め、根本的な目標、必要な能力、アーキテクチャを連携させながらバイブコーディングをしたときに初めて、管理可能な開発方法になります。伝統的な開発方法では、とにかくプロジェクトにおける役割が明確に区分されています。つまり、アーキテクト、設計者、プログラム開発者、テスターなどに分けられる場合が多いです。また、基盤技術もデータベース設計者、配置担当者などに分けられます。しかし、バイブコーディングをしてみると、これらの区分が曖昧になることがわかります。つまり、ルーチン化されたもの、How に該当するものは、あまりにも簡単に、あまりにも速く行われます(自動的に)。

[図-7] 伝統的な開発とバイブコーディングの段階と労力の違い

結果として、バイブコーディングを利用する開発者としては、経験ある(「感」のある)開発者がより適応しやすいということです。そのため、新人開発者をどのようなプロセスで素早く教育して「感」のある、つまり、「マルチジョブ開発者(真のリーン-Lean 開発者)に育てるか」が課題になりそうです。

## 10.より良いバイブコーディングのためのヒント

ソフトウェア開発方法は、コンピュータが初めて導入されて以来、継続的に発展してきました。継続的な発展の焦点は、コードの重要性に加え、継続的に上位段階に移動してきました。つまり、最初はコード化(Micro Code)自体から、次はプログラミング(Cobol)、次は設計(Structured Design)、次は分析(UML)、次は業務(Information Engineering)、次は顧客価値(Design Thinking, Customer Get Job Done)に移行してきました。 本プロジェクトを進めながら確信を持てる部分は、[図-8]に示すように、思ったより AI ができる部分が大きいということが徐々に緑色の部分に拡大しているということです。過去のソフトウェア開発プロセスがそう発展してきたように、AI が代替できること(貢献できること)も同じパターンで行われていることがわかります。これはアプリケーション開発部門だけを見た場合であり、本プロジェクトのシステムがやろうとしていることまで含めると、このようなパラダイムの変化が急速に進むことが推測できます。

[図-8] 開発段階による領域分類

より良いバイブコーディングをするためには(別の側面から見ると、人間開発者が価値を維持するためには)何に焦点を当てるべきでしょうか。まず、要件に対する正確な理解です。要件にはビジネス要件と IT 要件があります。ビジネス要件は、外部競争環境の変化(PESTNL-政治的、経済的、社会的、技術的、自然的、法的)変化、顧客価値、事業領域での競争構図、そして戦略を基にしたビジネス変化に対する理解をもとに、ビジネスモデルの再設計に対する要求であり、IT 要件は、このようなビジネス要件が運営モデルとして定着できるように技術基盤であるシステムを改善または具備する要件と見ることができます。前述の説明から、IT 要件はIT アーキテクチャーの連携がより一層重要になることが分かります。IT アーキテクチャーを定義することも AI の支援を受けて定義が可能ですが、アーキテクチャーは戦略を実現するものであるため、企業によって異なる可能性がある部分です。したがって、アーキテクチャーに対する教育と実践が強化されたとき、バイブコーディングの効果を高めることができます。さらに重要なのはビジネスモデルです。企業はビジネスを通じて企業の価値を高めます。企業の価値定義、製造、伝達、獲得に関連するビジネスがよく定義されていれば、バイブコーディングの効果が最大化されます。本プロジェクトの目標であったビジネス能力ファクトリーを構築しようとした一次的な目的は、よく定義されたビジネスモデルに基づいてビジネスを直接実行させる(全くコーディングが必要ない)システムを構築することでした。また、このようなシステムを通じて企業のほとんどの作業(IT 開発及び業務運営プロセス)を自動化することでした。 では、これを可能にするものは何でしょうか?

それは、企業のデジタルツインです。企業のデジタルツインは、企業のビジネスモデルから毎日すべての従業員が行うすべてのこと(知識)をビジネスオントロジーベースで詳細化・定義し、デジタル化したものです。そのため、本プロジェクトにビジネス能力ファクトリーでプロセスがすぐに実行可能になるのです。 このようなデジタルツインはどのように構築できるのでしょうか?今のところ、業務専門家やビジネスモデラーがこれらの作業を行うことができます。まだこのような作業を AI が完全に代替することは難しいと考えます。その理由は、企業ごとに企業のビジョンや価値、目標が異なり、従業員の能力レベルが異なるからです。

国内ではまだ適用事例はありませんが、海外では多くの企業がビジネスオントロジーモデルを構築するための努力をしています。私たちはこのようなプロジェクトを海外で 10 年前から行っており、現在、約 20 社以上の企業で同様のプロジェクトが行われています。私たちが参加したある金融機関のプロジェクトを例に挙げると、数千の顧客価値定義、千数百の価値製造、伝達、獲得活動、約 4 千の業務タスク、数千の意思決定のための報告書とデータライン、そして数百の業務動詞と数万の業務名詞が定義されました。それぞれの概念は目的、定義、範囲が明確に定義され、これら間の関係が多次元的に定義されました。このようなビジネスオントロジーモデルを基盤に、ビジネス革新と運営モデルの変化(業務改善と IT 開発)に敏捷性と顧客価値の最大化を目指しています。本プロジェクトは、このようなビジネス革新及びモデルプラットフォームでまるでプログラムを展開するように、業務運営プロセスを直接展開して実行することを目標としました。

##11.結論

バイブコーディングは、現代のソフトウェア開発環境で開発者の創造性と持続可能性を高める新しいパラダイムです。これは単純な開発方法論を超え、開発者が自分の仕事に価値を加え、より良い成果物を作り出すことができるように支援する方法です。とはいえ、バイブコーディングは開発者にとっては脅威になることもあります。開発者が先に紹介した考え方に適応しなければ、代替される危険性を持っています。したがって、開発者はこれから新しい考え方と作業方法に慣れなければならないでしょう。

企業はバイブコーディングという新しい開発方式に多くのチャンスを見つけることができます。しかし、企業のビジネスが透明に定義されなければ、バイブコーディングは他の企業の先進的な手法に過ぎず、効果を享受するのに制約があります。貴社のビジネスはどこにあるのでしょうか?もしかしたら、従業員の頭の中やLegacy プログラムだけに存在しているのではないでしょうか? このような企業は、おそらく効果を十分に享受することができません。さあ、今から企業のデジタルツイン構築を始めましょう。開発者は新しい思考とメタ認知的な実行方法に対する試みを始めましょう。新しいパラダイムの波は思ったより近くに来ています。

皆さんが徹底した準備で波を乗り切ることを願っています。

 

付録 : 伝統的な開発方式とバイブコーディングの違い

 

伝統的な開発

Vibeコーディング

アプローチの根本的な違い

  • すべての関数、変数、ロジックを自分で入力する
  • 構文と文法を正しく覚えて書く
  • 「HOW」に焦点を当てる:それをどのように実装するか?
  • 自然言語で意図と目的を伝える
  • AIと連携して実装が完了
  • 「何を」と「なぜ」に焦点を当てる:何を作るのか、なぜそれが必要なのか?

開発者の役割の変化

  • コードライター→すべての行を自分で書きます
  • 文法の専門家 → 各言語のフレーズを暗記する
  • デバッガ → 行ごとにトレースし、エラーを修正します
  • 実装者→ デザインをコードに変換する
  • アーキテクト→システム全体構造設計
  • AI→コミュニケーターと効果的にコミュニケーションをとる
  • キュレーター→AIの提案がレビューされ、キュレーションされました
  • 創造的な解決策を探求するイノベーター→

開発プロセスの違い

  • 要件分析
  • 詳細設計
  • コードの記述(行ごと)
  • コンパイル/実行
  • デバッグ
  • 繰り返し
  • ビジョンと目標の設定
  • AIによるアイデアのブレインストーミング
  • プロトタイプをすばやく作成
  • リアルタイムのフィードバックと改善
  • 反復進化
  • 最終レビューと最適化

生産性とスピード

  • 定型コードを書くのに時間がかかる
  • 構文エラーを探すのに時間を無駄にする
  • 新しいスキルを習得するのに長い時間がかかる
  • 多くの反復的なタスク
  • ボイラープレートはAIによって即座に生成されます
  • 構文エラーはほとんどない
  • 会話を通じた新技術の迅速な適用
  • クリエイティブな仕事により多くの時間を費やす

私たちが学び、成長する方法

JavaScriptの

開発者はすべてのパターンを自分で学習し、記憶します

関数 traditionalLearning() {

記事を読む

例に従って、

試行錯誤を繰り返す

久しぶりに覚えた

}

JavaScriptの

AIとの会話による即時学習

「このパターンをオブザーバーパターンにリファクタリングしたい」

→ AIが実装を解説付きで提示

リアルタイムで→を理解し、修正する

→ 迅速な学習と応用

問題解決型アプローチ

  • 一人で考え、解決策を見つける
  • Stack Overflow 검색
  • ドキュメントを読む
  • 試行錯誤で解決
  • AIとブレーンストーミング
  • 複数のソリューションを即座に比較
  • 最適な方法の選択
  • ラピッドプロトタイピングと検証

コードの品質と一貫性

  • 開発者の個人的なスタイルによります
  • コードレビューによる事後分析の改善
  • 一貫性を保つのが難しい
  • 品質は経験に大きく依存します
  • AIがベストプラクティスを自動的に適用する
  • リアルタイムのコード品質フィードバック
  • 一貫したコーディングスタイルを簡単に維持できます
  • ジュニアは、シニアレベルのコードを生成することもできます

創造性と実験

  • 最初に実装の実現可能性を検討してください
  • 使い慣れたパターンで作業する
  • 実験試験の高コスト
  • 保守的なアプローチ
  • 「そんなことがあり得るの?」から始める
  • さまざまなアプローチをすばやく試す
  • 非常に低コストの実験
  • 革新的な試みを奨励する

主な違い

Vibeコーディングは、開発者を「コードタイピスト」から「ソフトウェアアーキテクト」へと進化させます。AIは反復的で機械的なタスクを処理し、開発者は創造性、問題解決、ビジネス価値の創造に集中します。

これは、ツールの使用の違いだけでなく、開発に対する考え方やアプローチ方法のパラダイムシフトです。電卓の出現により、数学者が単純な計算から解放され、より複雑な理論的研究に集中できるようになったように、Vibeコーディングにより、開発者はより高レベルの問題の解決に集中できます。

参考資料 :

  1. 実際の実行ビデオ : Business Capability Factory-DREAMER
  2. 参考資料 : http://www.bmgovernance.com
    1.  

AIがバックエンドアプリケーション開発を強化

LLMは探査ソリューションを強化します

大規模な言語モデルと AI ツールを活用することで、ソリューションをより効率的に開発および最適化できます。問題を理解することがソリューション開発の中心です。当社は、顧客、パートナー、社内チームと徹底的な話し合いを行い、お客様のニーズと期待を理解します。私たちは大規模な言語モデルを使用してこれらの会話を分析および解析し、問題の核心をより深く理解します。

当社では、ビジネス モデルとナレッジ ファクトリーを使用してソリューションを定義および最適化します。問題の明確化と解決策の構築のプロセスは、人工知能ツールによって支援されます。これには、将来の傾向を予測するための機械学習アルゴリズムの使用、明示的および暗黙的な質問を解釈するための自然言語処理ツールの使用、または問題への関連性や解決策の可能性を深く探るための大規模言語モデルの使用が含まれる場合があります。

プロンプトを定義することは、このプロセスにおけるもう 1 つの重要なステップです。ヒントは、問題をより深く理解し、可能な解決策を見つけるのに役立ちます。これらのプロンプトでは、質問の目的を明確に表現するだけでなく、期待される回答の形式と推論パラメータも定義する必要があります。ソリューションを検討した後、AI を使用してソリューションの効果をシミュレートできます。大規模な言語モデルを使用して、可能な解決策を生成することもできます。各ソリューションの長所と短所を比較して評価し、最適なソリューションを見つけることもできます。

最適なソリューションが見つかったら、それをテストして検証します。私たちは人工知能ツールを使用してソリューションの実際の効果をシミュレートし、大規模な言語モデルを使用してテスト レポートを生成します。これらのレポートを使用して、ソリューションを調整および最適化します。

要約すると、大規模な言語モデルと AI ツールを使用することで、より効率的に問題を理解し、解決策を構築および探索し、テストおよび検証できるようになります。このアプローチにより、効率が向上するだけでなく、より高品質のソリューションを提供することも可能になります。

AIが設計ITモデルを強化

ビジネスモデルを運用する上で、まず顧客は誰なのか、顧客の期待は何か、企業が提供する価値は何なのか、顧客が好むチャネルは何なのか、パートナーは誰なのか、そして顧客価値を創造するためのプロセスとリソースは何かを明確にする必要があります。これらはビジネスモデルの中核部分です。

ソリューション開発フェーズでは、可能なビジネス ソリューションまたはデジタル ソリューションを検討する必要があり、そのためにはナレッジ ファクトリーとの連携が必要です。大規模言語モデルとビジネス オントロジーは、ソリューション開発において重要な役割を果たします。ソリューションが定義された後、まずプロセス ワークフロー、画面、レポート、意思決定ルールなどの運用レベルのビジネス モデルをシミュレートして検証されます。 2 番目に、大規模な言語モデルからマイニングされたデジタル ソリューションをローコード環境で実行できます。

ビジネス ソリューションを実装するプロセスでは、まず IT 目標とビジネス アーキテクチャに基づいて IT アーキテクチャを設計し、次に IT モデルを設計、つまり IT ソリューションを定義し、最後にプログラミングとテストを行う必要があります。 IT モデルを設計する際に、ビジネス モデルと AI ツールを使用して自動的に設計することができます。ビジネスモデルは、4 段階のタスクと 5 段階のステップを定義し、サービスの入出力構造を明確にし、ビジネス上の意思決定ロジックを定義し、チャネルや製品などのプロセスの変化要因を組み込みます。

AI ツールとビジネス モデルを使用することで、バックエンド アプリケーションの開発を加速できます。 IT アーキテクチャとアプリケーション パターンの設計に基づいて、ビジネス モデルに応じた UML モデルを自動的に生成できます。対象となるビジネスコンポーネントとコンポーネントアプリケーションパターンに基づいて、IT サービスの構造を設計できます。意思決定モデルの助けを借りて、ビジネスロジックを自動的に実装できます。エンティティ モデルとプロセス モデルに基づいて、サービスの入力と出力を定義できます。エンティティ モデルとデータ アーキテクチャに基づいて、データベース構造を設計できます。最後に、AI ツールを使用して IT モデルを自動的に設計するために、トランザクション サービスと分析サービスを区別できます。

AIプログラミング

運用レベルのビジネス モデルは、企業の日常的な業務運営にとって非常に重要です。ビジネス モデルには、価値提案、プロセス モデル、エンティティ モデルが含まれます。価値提案とは、顧客の価値期待と企業およびそのパートナーの製品やサービスとの間の価値をマッピングする方法です。本質的には、価値領域全体にわたって顧客、製品、チャネル、パートナーを連携させることです。プロセス モデルは顧客の価値期待を生み出すコア アクティビティを表し、物理モデルは価値を生み出すために使用されるリソースを表します。したがって、ビジネス モデリングの中核は、顧客が誰であるか、顧客が何を期待しているか、企業が提供する価値は何であるか、顧客が好むチャネルは何であるか、パートナーは誰であるか、顧客価値を創造するプロセスは何であるか、顧客価値を創造するためのリソースは何であるかを定義することです。

ビジネスモデルには、現在のビジネスモデルと目標とするビジネスモデルの 2 種類があります。目標要件を達成するには、ビジネスソリューションを定義して現在のモデルを目標モデルにアップグレードする必要があります。ソリューションを定義するには、ソリューションの検出と検証が鍵となります。

ソリューションの検出と研究開発は、ビジネス ソリューションまたはデジタル ソリューションを探索するプロセスであり、ナレッジ ファクトリーとの連携が必要です。大規模言語モデルとビジネス オントロジーは、ソリューション開発において重要な役割を果たします。 ChatGPT などの大規模言語モデルを活用すると、必要な機能を特定し、問題に対する解決策を見つけるのに役立ちます。このプロセスでは、質問の設計が非常に重要です。ヒントは、質問の目的、回答の形式、推論ハイパーパラメータ、コンテキストに基づいて設計する必要があります。ソリューションが定義されたら、ソリューションの検証が必要になります。確認方法は2つあります。 1 つは、プロセス ワークフロー、画面、レポート、意思決定ルールなどの運用レベルのビジネス モデルをシミュレートすることです。運用レベルのビジネス モデルはコードなしで実行できます。もう 1 つのアプローチは、マイニングされたデジタル ソリューションをローコード環境で実行することです。このデジタル ソリューションは、大規模な言語モデルからマイニングされ、要件エンジニアリングのソリューション ファクトリーのコンテキストで実行できます。このように、すべてのビジネス ソリューションはすでにビジネス モデルに組み込まれています。

次のステップは、ビジネス ソリューションを実装することです。ビジネス ソリューションを実装するプロセスでは、まず IT 目標とビジネス アーキテクチャに基づいて IT アーキテクチャを設計し、次に IT モデルを設計、つまり IT ソリューションを定義し、最後にプログラミングとテストを行う必要があります。 IT モデルを設計する際に、ビジネス モデルと AI ツールを使用して IT モデルを自動で設計することができます。 IT アーキテクチャとアプリケーション モデルに基づいた設計により、IT モデルの自動設計を実現できます。自動プログラミングは、大規模な言語モデルと AI プログラミング ツールを使用して実現できますが、品質を保証するには、オントロジー モデルに基づくビジネス モデルと、ビジネス アーキテクチャと IT 目標に基づく詳細な IT アーキテクチャ設計に基づく必要があります。 IT アーキテクチャには、アプリケーション モデル設計、コード構造モデル、AI エージェント、ソリューション統合が含まれており、これらは自動プログラミングを実現するための重要なコンポーネントです。

つまり、オントロジー モデルに基づいて構築されたビジネス モデルは、AI プログラミングにとって非常に重要です。まず、ビジネス モデルにはビジネス ソリューションが含まれており、ビジネスのデジタル ツインであり、デジタルで検証されたソリューションであるため、より正確です。 AIプログラミングには、ITモデルとAIツールの連携プラットフォームが必要です。オントロジーモデルは、ビジネスモデル、ITモデル、AIを接続するための基盤となるため、オントロジーモデルに基づくビジネスモデルが最適な基礎となります。最後に、AI プログラミングの一貫性は、アプリケーション パターン、コード構造、AI エージェントなどを含む詳細な IT アーキテクチャ設計に依存します。これらはすべて、ビジネス モデルに基づいて AI プログラミングを実装するために必要です。

Translated by google translator…