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コーディング |
|
|---|---|---|
|
アプローチの根本的な違い |
|
|
|
開発者の役割の変化 |
|
|
|
開発プロセスの違い |
|
|
|
生産性とスピード |
|
|
|
私たちが学び、成長する方法 |
JavaScriptの 開発者はすべてのパターンを自分で学習し、記憶します 関数 traditionalLearning() { 記事を読む 例に従って、 試行錯誤を繰り返す 久しぶりに覚えた } |
JavaScriptの AIとの会話による即時学習 「このパターンをオブザーバーパターンにリファクタリングしたい」 → AIが実装を解説付きで提示 リアルタイムで→を理解し、修正する → 迅速な学習と応用 |
|
問題解決型アプローチ |
|
|
|
コードの品質と一貫性 |
|
|
|
創造性と実験 |
|
|
|
主な違い |
Vibeコーディングは、開発者を「コードタイピスト」から「ソフトウェアアーキテクト」へと進化させます。AIは反復的で機械的なタスクを処理し、開発者は創造性、問題解決、ビジネス価値の創造に集中します。 これは、ツールの使用の違いだけでなく、開発に対する考え方やアプローチ方法のパラダイムシフトです。電卓の出現により、数学者が単純な計算から解放され、より複雑な理論的研究に集中できるようになったように、Vibeコーディングにより、開発者はより高レベルの問題の解決に集中できます。 |
|
参考資料 ：
- 実際の実行ビデオ : Business Capability Factory-DREAMER
- 参考資料 : http://www.bmgovernance.com
-