💨

誰でも安定した動作を実現！構造化されたプロンプト設計「ブレインアーキテクチャ」について解説！

に公開
AI
プロンプトエンジニアリング
コンテキストエンジニアリング
tech

はじめに

プロンプトを書いてこう思ったことはありませんか？

「人によってプロンプトの書き方が違うのが困る」
「プロンプトがぐちゃぐちゃでどこも変更したくない / 変更したらどんな影響が出るか分からない」

そんな方々にオススメしたいのが、ブレインプロンプトアーキテクチャです。（以降ブレインアーキテクチャと呼びます）

詳細はGitHubに記載しているので、さくっと知りたい方は本記事を読み進めてください。
https://github.com/nagineko/brain-prompt-architecture

ブレインアーキテクチャとは？

ブレインアーキテクチャは、行動心理学における情報処理モデルをシステムアーキテクチャに落とし込んだアーキテクチャです。

これにより、人間の思考プロセスを模倣するプロンプトを作成でき、誰が書いても安定して意図した動作を行いやすいプロンプトを作成することができます。

また、プロンプトを構造化して管理できる利点もあるため、プロンプトが混沌とし「どのプロンプトを修正すれば良いのか分からない」ケースが発生しにくくなります。

ブレインアーキテクチャの構造について

ブレインアーキテクチャの構造は、画像のような複数の層からなる構造を採用しています。

それぞれの層は矢印の方向にしか影響を与えず、明確に役割が異なります。
以下にそれぞれの層について説明を記載します。

Usecase層

LLMに実行させるタスクのユースケースを定義する層です。
TODOアプリの開発を例にすると、例えば以下のユースケースが考えられます。

TODOアプリを実装したい

このユースケースをプロンプトに変換すると、次のようになります。

# Usecase: TODOアプリを実装する

ここで重要なのは、どんなTODOアプリを実装したいか言語化することです。
何のプログラミング言語やフレームワークを使いたいか、またどんな機能が必要かを言語化します。

今回はTypeScriptのReactを使って、ログイン機能が付いたTODO Webアプリを作りたいと仮定します。
さらにTODO機能としては、個人ごとに複数のTODO名と内容を作成できるというシンプルな機能を考えてみます。
この場合、以下のようにプロンプトを更新します。

# Usecase: TypeScriptのReactを使って、ログイン機能の付いたTODOアプリを実装する。TODO機能としては個人ごとに複数のTODO名と内容を作成できる必要があります。

また、複数のユースケースがある場合は次のようにプロンプトを実装します。

# Usecase: TODOアプリを実装する
<Input層 ~ Cycle層のプロンプト>

# Usecase: 天気予報アプリを実装する
<Input層 ~ Cycle層のプロンプト>

Input層

LLMに実行させるタスクの入力処理に関するプロンプトを定義する層です。
ここではタスクを処理するために必要な情報を取得するよう、プロンプトを実装します。

## Input
### Trigger
‐ ログイン機能を実装する場合
‐ TODO機能を実装する場合

### Action
- 仕様書1ページ目に記載されている、ログイン機能に関する仕様を参照してください。
- 仕様書2ページ目に記載されている、TODO機能に関する仕様を参照してください。

Trigger層

LLMが実行するタスクの入力処理に関わるプロンプトのうち、トリガーとなるプロンプトを定義します。
TODOアプリケーションの開発を例に挙げると、以下のようなトリガーが考えられます。

- ログイン機能の実装時
- TODO機能の実装時

このトリガーをプロンプトに変換すると、次のようになります。

### Trigger
‐ ログイン機能を実装する場合
‐ TODO機能を実装する場合

Action層

LLMに実行させるタスクの入力処理に関するプロンプトのうち、トリガーの条件を満たした場合、どんな入力処理を実行するか定義するプロンプトを実装します。
TODOアプリの開発を例にすると、例えば以下のアクションが考えられます。

- 仕様書1ページ目に記載されている、ログイン機能に関する仕様を参照してください。
- 仕様書2ページ目に記載されている、TODO機能に関する仕様を参照してください。

このアクションをプロンプトに変換すると、次のようになります。

### Action
- 仕様書1ページ目に記載されている、ログイン機能に関する仕様を参照してください。
- 仕様書2ページ目に記載されている、TODO機能に関する仕様を参照してください。

Process層

LLMに実行させるタスクの処理自体に関するプロンプトを定義する層です。
ここではタスクを処理するために必要な情報を取得するよう、プロンプトを実装します。

## Process
### Trigger
- プログラムを実装している場合
- プログラムの動作確認をしている場合

### Action
- 構文エラーが発生しないか、動作確認してください。
- 型エラーが発生しないか、動作確認してください。
- 仕様を満たす動作をしているか、動作確認してください。

Trigger層

LLMに実行させるタスクの処理自体に関するプロンプトのうち、トリガーとなるプロンプトを実装します。
TODOアプリの開発を例にすると、例えば以下のトリガーが考えられます。

- プログラムを実装している場合
- プログラムの動作確認をしている場合

このトリガーをプロンプトに変換すると、次のようになります。

### Trigger
- プログラムを実装している場合
- プログラムの動作確認をしている場合

Action層

LLMに実行させるタスクの処理自体に関するプロンプトのうち、トリガーの条件を満たした場合、どんな処理を実行するか定義するプロンプトを実装します。
TODOアプリの開発を例にすると、例えば以下のアクションが考えられます。

- 構文エラーが発生しないか、動作確認してください。
- 型エラーが発生しないか、動作確認してください。
- 仕様を満たす動作をしているか、動作確認してください。

このアクションをプロンプトに変換すると、次のようになります。

### Action
- 構文エラーが発生しないか、動作確認してください。
- 型エラーが発生しないか、動作確認してください。
- 仕様を満たす動作をしているか、動作確認してください。

Output層

LLMに実行させるタスクの処理後に関するプロンプトを定義する層です。
ここではタスク処理後にどんな処理をさせて終了したいかを定義するよう、プロンプトを実装します。

## Output
### Trigger
- プログラムの実装を終了した場合

### Action
- 生成したプログラムとプログラムのファイル名のみをユーザーに提供してください。
- 仕様に不明瞭点がある、または動作に不明瞭点がある場合は、不明瞭点が解消するようユーザーに質問してください。

Trigger層

LLMに実行させるタスクの処理後に関するプロンプトのうち、トリガーとなるプロンプトを実装します。
TODOアプリの開発を例にすると、例えば以下のトリガーが考えられます。

- プログラムの実装を終了した場合

このトリガーをプロンプトに変換すると、次のようになります。

### Trigger
- プログラムの実装を終了した場合

Action層

LLMに実行させるタスクの処理後に関するプロンプトのうち、トリガーの条件を満たした場合、どんな処理を実行するか定義するプロンプトを実装します。
TODOアプリの開発を例にすると、例えば以下のアクションが考えられます。

- 生成したプログラムとプログラムのファイル名のみをユーザーに提供してください。
- 仕様に不明瞭点がある、または動作に不明瞭点がある場合は、不明瞭点が解消するようユーザーに質問してください。

このアクションをプロンプトに変換すると、次のようになります。

### Action
- 生成したプログラムとプログラムのファイル名のみをユーザーに提供してください。
- 仕様に不明瞭点がある、または動作に不明瞭点がある場合は、不明瞭点が解消するようユーザーに質問してください。

Cycle層

タスク実行の終了条件を定義するプロンプト層です。
もしタスク実行の終了条件を満たせない場合、Cycleで定義されたプロンプトに従い条件を変更してタスクを再実行する必要があります。
TODOアプリの開発を例にすると、例えば以下の終了条件が考えられます。

- TODOアプリのアプリケーションコードを全て実装するまで思考を続けること

この終了条件をプロンプトに変換すると、次のようになります。

## Cycle
- TODOアプリのアプリケーションコードを全て実装するまで思考を続けること

Knowledge層

LLMがAction層のプロンプト実行のため参照する、またはAction層の実行結果を必要に応じて記憶する層です。
ここではActionをドメイン知識や前提知識を定義するよう、プロンプトを実装します。
TODOアプリの開発を例にすると、例えば以下の前提知識が考えられます。

- TODOアプリのユーザーについて
  - ユーザーは20代〜30代の男性です。エンジニアとして働いており、コーディングの時にふと生まれるTODOをまとめられるTODOアプリを必要としています。

この前提知識をプロンプトに変換すると、次のようになります。

# Knowledge
- TODOアプリのユーザーについて
  - ユーザーは20代〜30代の男性です。エンジニアとして働いており、コーディングの時にふと生まれるTODOをまとめられるTODOアプリを必要としています。

まとめ

人間の思考プロセスに基づいたプロンプトを構造化して実装することで、誰が書いても安定した出力が得られやすくなります。
さらにプロンプト自体の保守性・メンテナンス性の向上に貢献します。

「人によってプロンプトの書き方が違うのが困る」
「プロンプトがぐちゃぐちゃでどこも変更したくない / 変更したらどんな影響が出るか分からない」
と感じている方は、ぜひこのアーキテクチャを取り入れてプロンプトを実装してみてください。

Discussion