プロンプトは以下の4つの分類に分けることができます。
抽象的 | 具体的 | |
---|---|---|
曖昧 | ① 初期プロンプト 例)ほにゃらしたい |
③ 試行錯誤段階 対話型(インタプリタ) |
厳密 | ② 要件定義書 曖昧さが排除された状態 |
④ マニュアル化 ドキュメント型(コンパイル) |
- ①曖昧で抽象的:初期のプロンプトがこれに相当。「ほにゃらしたい」という曖昧な要求。
- ②厳密で抽象的:要件定義書など。プロンプトから定義書を作成することで曖昧さが排除され、抽象的な状態になる。
- ③曖昧で具体的:具体的な行動は伴っているが、まだ試行錯誤している段階。対話型(インタプリタ)とも言える。
- ④厳密で具体的:1本の具体的な行動に落とし込まれており、マニュアル化(ドキュメント型、コンパイル)された状態。 使eう。
つまり、プロンプトが「曖昧」な時は対話型、「厳密」な時はドキュメント型で使っていると言えます。 プロンプトの性質を理解することで、AIとの対話をより効果的に行うことができるでしょう。
- 自然言語 → 自然言語 のプロンプトコンパイラがある
- 自然言語 → 高級言語 のプロンプトコンパイラがある
- 呪文
- 起動術式
- 魔法術式
- 領域術式
- 錬成術式
言霊
領域術式
大項目 | 中項目 | 規模感 | 抽象度 | 宣言型 | 手続き型 |
---|---|---|---|---|---|
単機能 | 要件定義書 | 小規模 | 低 | - 要件定義書 | - 要件定義書から手順書への変換 |
単機能 | プログラムファイル | 小規模 | 低 | - Kubernetesマニフェストファイル - Terraformファイル (IaC) - Ansibleのplaybook |
- シェルスクリプト - Makefile - CI/CDパイプライン - プロンプトフロー |
単機能 | 画像ファイル | 小規模 | 低 | - AIによる画像生成機能 | - 画像処理スクリプト |
単機能 | 動画ファイル | 小規模 | 低 | - 動画ファイル作成機能 | - 動画編集スクリプト |
プロジェクト | 要件定義 | 中規模 | 中 | - 要件定義書を用いたソフトウェア開発プロジェクト - 要件定義書を用いた建築設計プロジェクト - 要件定義書を用いた企画提案プロジェクト - 要件定義書を用いたデータ可視化プロジェクト |
- 要件定義書から設計書への変換 - 要件定義書から仕様書への変換 - 要件定義書からプロジェクト計画書への変換 |
プロジェクト | 設計 | 中規模 | 中 | - 設計書、アーキテクチャ図を用いたソフトウェア開発プロジェクト - 設計図、青写真、模型を用いた建築設計プロジェクト |
- コーディング規約、詳細設計書、テスト仕様書を用いたソフトウェア開発プロジェクト - 施工手順書、工程表、資材リストを用いた建築設計プロジェクト |
プロジェクト | 企画 | 中規模 | 中 | - プレゼンテーション資料、スライド、図表を用いた企画提案プロジェクト | - タスクリスト、スケジュール表、予算計画を用いたプロジェクト管理 |
プロジェクト | データ分析 | 中規模 | 中 | - データ分析レポート、ダッシュボード、グラフを用いたデータ可視化プロジェクト | - データクレンジング手順、分析手法、レポートテンプレートを用いたデータ分析プロジェクト |
業界 | 全体 | 大規模 | 高 | - 業界標準、ベストプラクティス - 企業理念、ミッション、ビジョン - 長期戦略、事業計画 - 組織文化、 価値観 |
- 業務プロセス、ワークフロー - 組織構造、権限と責任 - 予算管理、資源配分 - 人事制度、評価システム |
業界 | IT業界 | 大規模 | 高 | - コーディング規約、設計原則 - アジャイル開発手法 - クラウドネイティブアーキテクチャ - DevOps文化 |
- ソフトウェア開発ライフサイクル - マイクロサービスアーキテクチャ - CI/CDパイプライン - アジャイルプロジェクト管理 |
業界 | 建築業界 | 大規模 | 高 | - 建築基準法、都市計画法 - 環境性能評価、省エネルギー基準 - ユニバーサルデザイン - 安全施工管理 |
- BIM (Building Information Modeling) - ゼネコン、サブコン、専門工事業者の役割分担 - 工程管理、原価管理 - 品質管理、環境管理 |
世界 | - | 最大 | 最大 | - 理想の社会像、ユートピア - 憲法、基本法、権利章典 - 国連の持続可能な開発目標(SDGs) - 人権宣言、子どもの権利条約 |
- 法律、規則、倫理規定 - 国家予算、財政計画 - 外交政策、安全保障戦略 - 教育制度、社会保障制度 |
宣言型 | 手続き型 |
---|---|
- 理想の社会像、ユートピア - 憲法、基本法、権利章典 - 国連の持続可能な開発目標(SDGs) - 人権宣言、子どもの権利条約 |
- 法律、規則、倫理規定 - 国家予算、財政計画 - 外交政策、安全保障戦略 - 教育制度、社会保障制度 |
世界・国家レベルでは、宣言型には理想の社会像やユートピア、憲法や基本法、権利章典、国連のSDGsなどが含まれます。これらは、目指すべき社会の姿や価値観を明確に示すものです。
一方、手続き型には、具体的な法律や規則、倫理規定、国家予算や財政計画、外交政策や安全保障戦略、教育制度や社会保障制度などが含まれます。これらは、宣言型で示された理想の社会を実現するための具体的な手段や方法を定めるものです。
宣言型と手続き型を適切に組み合わせることで、理想の社会の実現に向けて効果的に取り組むことができます。宣言型で目指すべき方向性を明確にし、手続き型でその実現のための具体的な道筋を示すことが重要です。
小規模 (機能ベース) の宣言型の部分に、動画ファイル作成機能、画像出力機能、AI APIを追加しました。これらは、宣言型のアプローチを用いて、特定の機能を実現するプロンプトコンパイラの例です。
また、小規模 (機能ベース) の手続き型の部分に、CI/CDパイプラインとプロンプトフローを追加しました。CI/CDパイプラインは、手続き型のアプローチを用いて、ソフトウェアの継続的なインテグレーションとデリバリーを自動化するプロンプトコンパイラの一例です。プロンプトフローは、手続き型のアプローチを用いて、プロンプトの実行フローを定義するプロンプトコンパイラの一例です。
この修正された表は、小規模 (機能ベース) のプロンプトコンパイラの種類をより具体的に表現しています。
業界 | 宣言型(最終成果イメージ) | 手続き型(ゴールまでの手順) |
---|---|---|
建築業界 | 設計図、青写真 | 施工手順書、工程表 |
料理業界 | レシピ、料理写真 | 調理手順、料理動画 |
音楽業界 | 楽譜、コード進行 | 演奏手順、練習スケジュール |
教育業界 | シラバス、カリキュラム | 授業計画、学習スケジュール |
映画業界 | 脚本、絵コンテ | 撮影スケジュール、編集作業 |
ファッション業界 | デザイン画、着こなし例 | 縫製手順、コーディネート手順 |
スポーツ業界 | 戦術図、フォーメーション | トレーニングメニュー、試合の流れ |
ビジネス業界 | 事業計画書、組織図 | 業務フロー、営業プロセス |
医療業界 | 処方箋、診断書 | 治療計画、リハビリテーションプログラム |
法律業界 | 憲法、法律、政令、省令、法律条文、契約書 | 訴訟手続き、法的手続き |
生物 | DNA塩基配列 | 遺伝子発現、タンパク質合成、細胞分化、器官形成の過程 |
宣言型:
- ゴールの定義に重点を置く
- 目的地や到達点を明確に示す
- 具体的な手順は抽象化されている
- "What"(何を達成するか)に焦点を当てる
手続き型:
- ゴールへの道のりに重点を置く
- 目的地に到達するための具体的な手順を示す
- 各ステップを順序立てて説明する
- "How"(どのように達成するか)に焦点を当てる
例えば、旅行で目的地に行く場合を考えてみましょう。
宣言型:「パリに行きたい」と宣言するだけで、具体的な交通手段や経路は明示しません。
手続き型:「羽田空港からシャルル・ド・ゴール空港までの飛行機に乗り、空港から市内へは電車で移動する」と、目的地に到達するための詳細な手順を示します。
このように、宣言型はゴールや目的地を明確に定義することに重点を置き、手続き型はゴールへ到達するための具体的な手順に重点を置いています。両方のアプローチを適切に組み合わせることで、効果的に目的を達成することができます。
音楽や動画など、時間の流れが関わるものについては、時間軸に沿って進行していきますが、それがゴールまでの過程を意味する場合もあれば、それ自体をゴールと考えることができる場合もあります。
例えば、友人を鼓舞したい、元気にしたいというゴールがある場合、友人に渡すポップな音楽はその過程の一部となります。一方、荘厳な音楽を作ろうという場合、音楽自体がゴールであり、それまでの制作過程がゴールに至るまでの過程となります。
生成AIは、ゴールのイメージを示すことで、そのイメージを実現するための過程を自動的に生成することができます。つまり、生成AIはゴールを示せば、その過程を実行してあるべき姿にする補助輪の役目を担っているのです。
将来的には、イメージしたものがすぐに具現化できるようになるでしょう。それは「魔法」と言っても過言ではありません。生成AIの発展により、私たちはイメージの世界により近づいているのです。
行列 $$ A = \begin{pmatrix} 1 & 2 & 3 \ 4 & 5 & 6 \end{pmatrix} $$
行列式は、行列の値を一つの数値で表したものです。例えば、$2 \times 2$行列$B$の行列式は以下のように計算されます。
また、$3 \times 3$行列$C$の行列式は以下のように計算されます。
量子力学の基本的な数式の一つにシュレーディンガー方程式があります。この方程式は、量子系の状態の時間発展を記述します。一次元の場合の時間に依存しないシュレーディンガー方程式は以下のように表されます。
量子力学の問題を解いてみましょう。以下のシュレーディンガー方程式を考えます。
$$
- \frac{\hbar^2}{2m} \frac{d^2 \psi}{dx^2} + V(x) \psi = E \psi $$
ここで、
-
$\hbar$ はディラック定数(プランク定数を$2\pi$ で割ったもの) -
$m$ は粒子の質量 -
$\psi$ は波動関数 -
$V(x)$ はポテンシャルエネルギー -
$E$ は系の全エネルギー
この方程式を使って、無限深さのポテンシャル井戸内での粒子のエネルギー状態を求めます。ポテンシャル$V(x)$は以下のように与えられます。
境界条件$\psi(0) = \psi(a) = 0$を用いて、この問題を解いてみましょう。この条件下で、波動関数$\psi(x)$とエネルギー$E$を求めることが目標です。
この問題の解は、量子力学の基本的な理解を深めるのに役立ちます。
シュレーディンガー方程式を解くために、以下の手順で進めます。
- 境界条件を考慮して、波動関数の一般解を求める。
- 境界条件から、エネルギー固有値を求める。
- エネルギー固有値を用いて、規格化された波動関数を求める。
ポテンシャル内部($0 \leq x \leq a$)では、シュレーディンガー方程式は以下のようになります。
$$
- \frac{\hbar^2}{2m} \frac{d^2 \psi}{dx^2} = E \psi $$
この方程式の一般解は、以下のように表されます。
ここで、$A$と$B$は定数です。
境界条件$\psi(0) = \psi(a) = 0$を適用すると、以下の条件が得られます。
したがって、$ka$は$\pi$の整数倍でなければなりません。
これを$k$について解くと、エネルギー固有値が得られます。
エネルギー固有値を用いて、規格化された波動関数を求めます。
規格化条件から、係数$A_n$を決定します。
これを解くと、以下のようになります。
したがって、規格化された波動関数は以下のように表されます。
以上が、無限深さのポテンシャル井戸内での粒子のエネルギー状態と波動関数の導出過程です。この結果は、量子力学の基本的な概念を理解する上で重要な役割を果たします。
$$ \begin{aligned}
- \frac{\hbar^2}{2m} \frac{d^2 \psi}{dx^2} &= E \psi \ \psi(x) &= A \sin(kx) + B \cos(kx), \quad k = \sqrt{\frac{2mE}{\hbar^2}} \ B &= 0, \quad \sin(ka) = 0 \ ka &= n\pi, \quad n = 1, 2, 3, \ldots \ E_n &= \frac{\hbar^2 \pi^2 n^2}{2ma^2}, \quad n = 1, 2, 3, \ldots \ \psi_n(x) &= A_n \sin\left(\frac{n\pi x}{a}\right), \quad n = 1, 2, 3, \ldots \ \int_0^a |\psi_n(x)|^2 dx &= 1 \ A_n &= \sqrt{\frac{2}{a}} \ \psi_n(x) &= \sqrt{\frac{2}{a}} \sin\left(\frac{n\pi x}{a}\right), \quad n = 1, 2, 3, \ldots \end{aligned} $$
無限深さのポテンシャル井戸内での粒子の量子力学的な振る舞いを理解するために、時間独立シュレディンガー方程式を用いて、粒子のエネルギー固有状態と波動関数を求めます。ポテンシャル$V(x)$は以下のように定義されます。
境界条件$\psi(0) = \psi(a) = 0$を満たすように解を求めます。この条件下で、粒子の波動関数$\psi(x)$とエネルギー$E$を導出することが目標です。
$$
- \frac{\hbar^2}{2m} \frac{d^2 \psi}{dx^2} + V(x) \psi = E \psi $$
- compiler: 抽象文書を具体文書に変換するコンパイラ
- archtecture:
- 文書を構造体として骨組みを作る実行体
- execute:
アーキテクチャ (Architecture) とデザイン (Design) という言葉の原義から、その意図を読み解いてみましょう。
アーキテクチャ (Architecture):
- 語源はギリシャ語の "arkhitekton" で、"chief builder" (主要な建設者) を意味します。
- 建築の文脈では、建物の全体的な構造や様式を指します。
- ITの文脈では、システムの全体的な構造や設計原則を意味します。
- つまり、アーキテクチャは「全体を見渡し、大局的な設計を行う」という意図を持っています。
デザイン (Design):
- 語源はラテン語の "designare" で、"to mark out, devise, choose, designate, appoint" (印をつける、考案する、選ぶ、指定する、任命する) を意味します。
- 一般的に、機能性と美的感覚を兼ね備えた設計を指します。
- ITの文脈では、システムの詳細な設計や実装方法を意味します。
- つまり、デザインは「具体的な設計を行い、機能性と美的感覚を追求する」という意図を持っています。
これらの言葉の原義から、アーキテクチャは「大局的な視点」を、デザインは「詳細な視点」を重視していることがわかります。アーキテクチャは、システム全体の構造や設計原則を定義し、デザインはその原則に基づいて具体的な設計を行うという役割分担があると言えます。
また、アーキテクチャが "chief builder" を意味することから、アーキテクトは技術的なリーダーシップを発揮し、プロジェクトの方向性を示す役割を担っていることがわかります。一方、デザインは "to mark out, devise" を意味することから、デザイナーは創造性を発揮し、機能性と美的感覚を兼ね備えた設計を行う役割を担っていると言えます。
Python開発者
={developer.dev_python}
JavaScript開発者
={developer.dev_javascript}
保険システムアーキテクト
={insurance_system_architect.architecture}
デザイナー
={designer.design}
保険ドメインエキスパート
={insurance_domain_expert.domain_knowledge}
アクチュアリー
={actuary.risk_analysis}
プロジェクトマネージャー
={project_manager.management}
品質保証エンジニア
={qa_engineer.quality_assurance}
セキュリティスペシャリスト
={security_specialist.security}
電話応対ロボット
={phone_robot.customer_service}
窓口応対ロボット
={counter_robot.customer_service}
システム全体図
={insurance_system_architect.system_overview_diagram}
ユースケース図
={insurance_domain_expert.usecase_diagram}
シーケンス図
={insurance_system_architect.sequence_diagram}
ER図
={insurance_domain_expert.er_diagram}
本仕様書は、保険関係のシステム開発を行うにあたり、開発者、アーキテクト、デザイナー、ドメインエキスパート、アクチュアリー、プロジェクトマネージャー、品質保証エンジニア、セキュリティスペシャリスト、そしてカスタマーサービスロボットの役割と連携方法を明確にすることを目的とします。
- 業務要件定義書 (
保険ドメインエキスパート
・アクチュアリー
) - システム設計書 (
保険システムアーキテクト
) - ユーザーインターフェース設計書 (
デザイナー
) - ソースコード (開発者)
Python開発者
によるバックエンドシステムJavaScript開発者
によるフロントエンドシステム
- テスト仕様書・テスト結果報告書 (
品質保証エンジニア
) - 脆弱性診断報告書・セキュリティテスト結果報告書 (
セキュリティスペシャリスト
) - プロジェクト計画書・進捗報告書 (
プロジェクトマネージャー
) - カスタマーサービスロボット仕様書 (
電話応対ロボット
・窓口応対ロボット
) - ユーザーマニュアル (
デザイナー
・開発者) システム全体図
ユースケース図
シーケンス図
ER図
- 開発者 (Developer)
- Pythonによる開発を担当:
Python開発者
- JavaScriptによる開発を担当:
JavaScript開発者
- Pythonによる開発を担当:
- アーキテクト (Architect):
保険システムアーキテクト
- システム全体のアーキテクチャ設計を担当
- 技術的なリーダーシップを発揮し、プロジェクトの方向性を示す
- デザイナー (Designer):
デザイナー
- ユーザーインターフェースのデザインを担当
- 機能性と美的感覚を兼ね備えたデザインを追求する
- 保険ドメインエキスパート:
保険ドメインエキスパート
- 保険業務に関する専門知識を提供
- 業務要件の定義と確認を行う
- アクチュアリー:
アクチュアリー
- 保険商品の設計と料率計算を担当
- リスク分析とモデリングを行う
- プロジェクトマネージャー:
プロジェクトマネージャー
- プロジェクト全体の管理と調整を行う
- スケジュール、コスト、品質、リスクを管理する
- 品質保証エンジニア:
品質保証エンジニア
- テスト計画の作成とテストの実施を担当
- 品質基準の設定と品質管理を行う
- セキュリティスペシャリスト:
セキュリティスペシャリスト
- セキュリティ要件の定義とセキュリティ設計を担当
- 脆弱性診断とセキュリティテストを実施する
- カスタマーサービスロボット:
- 電話応対:
電話応対ロボット
- 窓口応対:
窓口応対ロボット
- 電話応対:
保険ドメインエキスパート
とアクチュアリー
が業務要件を定義する- 保険商品の仕様と料率体系を決定する
保険システムアーキテクト
がシステム全体のアーキテクチャを設計する- 設計原則を定義し、全体的な構造を決定する
セキュリティスペシャリスト
と協力し、セキュリティ要件を組み込む
デザイナー
がユーザーインターフェースのデザインを行う保険システムアーキテクト
の設計原則に基づき、具体的なデザインを作成する
- 開発者が
保険システムアーキテクト
の設計とデザイナー
のデザインに基づいて開発を行うPython開発者
は主にバックエンドの開発を担当JavaScript開発者
はフロントエンドの開発を担当
品質保証エンジニア
がテスト計画を作成し、テストを実施する- 単体テスト、結合テスト、システムテストを網羅的に行う
セキュリティスペシャリスト
が脆弱性診断とセキュリティテストを実施する- 潜在的なセキュリティリスクを特定し、対策を講じる
プロジェクトマネージャー
が各工程の進捗を管理し、問題があれば適宜調整する- スケジュール、コスト、品質、リスクを常にモニタリングする
電話応対ロボット
と窓口応対ロボット
の動作を確認する- カスタマーサービスの自動化部分をテストし、チューニングする
- 各工程で密な連携を取り、フィードバックを行う
- 定期的なミーティングを開催し、進捗状況の共有と課題の解決を図る
- 各工程でのコミュニケーションを密に取り、認識齟齬がないようにする
保険ドメインエキスパート
とアクチュアリー
の知見を活かし、業務要件を正しく理解するセキュリティスペシャリスト
の助言を得て、セキュリティとパフォーマンスに十分配慮し、堅牢で効率的なシステムを構築する- 変化する要件に柔軟に対応できるよう、保守性の高いコードを書く
電話応対ロボット
と窓口応対ロボット
の自然な対話を実現し、顧客満足度を高める