Takajo AI Lab

Project 01 — Prompt Engineering Standards

prompt-as-code.

私たちはいま、自然言語でコードを書いている。しかしそこには、コンパイラも lint も存在しない。
prompt-as-code は、プロンプトを実行可能なコードとして扱うための言語仕様である。

Abstract

なぜ Prompt に Syntax が要るのか。

私たちはいま、自然言語でコードを書いている。しかしそこには、コンパイラも lint も、型チェッカーも存在しない。未定義の変数、曖昧な指示、ハルシネーション——これらはすべて、プログラミング言語で言うところの Syntax Error である。

本仕様書は、プロンプトを実行可能なコードとして扱うための Language Specification(言語仕様)である。本 Lab はその標準化を、研究の中核に置く。

なぜ今、この仕様が要るのか。AI エージェントを組める人の定義が、コードの外側へ広がった——それは同時に、品質・統制・判断の責任が組織全体に分散した、ということでもある。時代背景を読む →

未定義の変数、曖昧な指示、ハルシネーション。
これらはすべて、Syntax Error である。

Philosophy

Takajo AI Lab の思想。

本仕様は Lab の思想に基づいて編まれている。魔法の呪文やコツを積み重ねる営みではなく、体系的な工学的原理を積み上げる営みとして、Prompt Engineering を再定義する試み。

目的は、プロンプト設計を、再現可能でテスト可能な手法群を持つ、堅牢な実務領域として確立することである。OpenAI・Anthropic・Google の公開知見、およびコミュニティの実践を、1 つの構造化された標準として統合する。

Why Now — 2026

時代が、変わった。

AI エージェントは、プログラミングができる人だけの宝石ではなくなった。

かつて、複雑なエージェント制御は LangGraph をはじめとするコードの領域だった。Lab もそこで CriticChain を組み、コードの力を確かめてきた。複数のエージェントを連携させ、敵対的な批評ループを回す——それはプログラミング言語の抽象化能力があって初めて可能な設計だった。

しかし スキル機能の台頭(Claude Skills / MCP / 自然言語オーケストレーション)が、その地図を書き換えた。自然言語——プロンプトだけで、複雑なエージェント的処理が走る時代になった。かつて「呪文芸」と矮小化されていたプロンプトエンジニアリングが、工学として復権したということである。

だが、本当に起きているのはプロンプトの復権だけではない。エンジニアでなくとも、組織の多くの席から AI エージェントが組めるようになった。結果として、組織の中で「誰が何を決めるか」が揺らぎはじめている。部門ごとに独自プロンプトが乱立する。品質監査を通さない AI 出力が本番で走る。事業部で組まれた自動化が、経営判断と矛盾する——これらは、もう遠い話ではない。

自然言語で動くからこそ、より厳格な管理が要る。

仕様書のないコード、テストの通らないコード、レビューを経ないコード——それが本番で走っている状態が、いま世界中のプロンプトで起きている。プロンプトが工学として復権したなら、工学の規律——仕様・再現性・レビュー・バージョン管理——を備えなければならない。

prompt-as-code は、その規律を定義する試みである。プロンプトを書き捨てのテキストではなく、実行可能なコードとして扱う。Syntax(構文)、Type(型)、Context(文脈)、Error(誤り)——これらを明示的に定義することで、自然言語の曖昧さを工学的に管理可能にする。

そしてこの仕様が 1 つあるだけでは足りない。それを使いこなす人を育てる Learn、出力を監査する CriticChain、そして全体を経営判断に接続する Work——標準・学習・審査基盤・戦略。この四つが揃って初めて、AI は組織の道具になる。

Prompt engineering must become engineering. プロンプトは工学に昇格する。
同時に、その工学を運用する組織の側も、再設計が要る。

Core Principles

三つの原則。

  1. § 01 Markdown-Native Syntax プロンプトは Markdown で書く。これが事実上の業界標準である。ヘッダー(#)、箇条書き(-)、コードブロック(```)を活用する。構造化された情報は、LLM にとって格段にパースしやすい。
  2. § 02 Principle of Explicitness 暗黙の指示を避ける。すべてを明示する。変数名、区切り子、手順番号をすべて明確に定義する。AI が「行間を読む」ことを、期待してはならない。
  3. § 03 Reproducibility 異なる実行でも一貫した結果を得られるように設計する。「前のチャットで述べたように」のような外部依存を持たない。コンテクストを明示的に管理する場合を除いて。

Specification — 仕様書

v0.3.0 の構成

仕様書は 10 セクションから構成される。Core Principles(原則)から始まり、変数宣言・区切り子・構造化パターンを経て、LLMOps やアンチパターンまでを扱う。

§ 1. Core Principles Markdown-Native / Explicitness / Reproducibility の 3 原則
§ 2. Variable Declaration {variable_name}: + """ を標準とする宣言形式
§ 3. Delimiters Triple Quotes / XML Tags / YAML を場面に応じて使い分ける
§ 4. Global Standards OpenAI / Anthropic / CO-STAR(Singapore GovTech)の各推奨パターン
§ 5. Structuring Patterns Role / Context / Goal / Constraints 他、8 構成要素
§ 6. Structured Reasoning SCoT、Chain of Verification (CoVe)、Chain of Density (CoD)
§ 7. Prompt Chaining 多段プロンプト・文脈管理・データ依存の追跡
§ 8. LLMOps バージョン管理・Observability・評価・ガバナンス
§ 9. Anti-patterns やってはいけない書き方の類型
§ 10. Debugging Glass Box 技法、変数検査、エラー切り分けチェックリスト

§ 2 — Variable Declaration

# ✅ Recommended

{target_audience}:
"""
Mid-level Sales Professional
Annual Income: $80,000
Location: New York City
"""

{pain_points}:
"""
Struggling with public speaking in English
Handling international negotiations
"""

# ❌ Avoid — headers are not variables
# Target Audience
# Mid-level Sales Professional

§ 6 — Chain of Verification (CoVe)

# Verified Answer Generation

[C1] Draft
Generate initial answer to {question}.

[C2] Plan Verification
Identify claims in {draft}
needing fact-checking.

[C3] Execute
Answer {verification_questions}
using external knowledge.

[C4] Revise
Based on {verification_results},
produce {final_answer}.

Debugging — Prompt Syntax Error

Prompt を、コードとして診る。

Prompt Linter が実際に返すエラーは、コンパイラエラーに似ている。場所・原因・修正方針が、構造化された診断として返る。以下は仕様の § 9 Anti-patterns を違反したプロンプトに対する、標準的な診断出力である。

prompt-lint — v0.3.0 — diagnostic 
$ prompt-lint check ./sales-pitch.prompt.md

# parsing … 14 lines, 2 variables, 1 structured block
# loading §1–§9 ruleset (prompt-as-code v0.3.0)

./sales-pitch.prompt.md:5:3
  error [PAC-E203] undefined variable referenced
   → § 2 · Variable Declaration
   → variable `{customer_profile}` used without declaration

    3 │  # Role
    4 │  You are a senior B2B sales strategist.
    5 │  – Tailor the pitch to {customer_profile}.
      │     ^^^^^^^^^^^^^^^^^^ not found in scope
    6 │  …

  hint: declare before use —
         {customer_profile}:
         """
         (… structured content …)
         """




./sales-pitch.prompt.md:9:1
  error [PAC-E107] implicit instruction — model must infer intent
   → § 1.2 · Principle of Explicitness
   → phrasing expects the model to “read between the lines”

    9 │  Make it sound more professional but also friendly.

  hint: specify both dimensions on explicit axes —
         register: formal | neutral | casual
         warmth:   reserved | balanced | warm




./sales-pitch.prompt.md:12:1
  warning [PAC-W312] external context dependency
   → § 1.3 · Reproducibility
   → reference to prior conversation breaks re-runnability

   12 │  As we discussed in the previous chat, apply the same tone.

  hint: inline the referenced material, or declare
         it as an explicit {prior_context} variable.




# summary
2 errors, 1 warning # violations of §1, §2 detected
run prompt-lint explain PAC-E107 for rule rationale.

$ _

エラーコードの命名(PAC-E203, PAC-E107, PAC-W312)は TypeScript / Rust コンパイラの規約に倣う。プロンプトが壊れているのではなく、仕様のどの条項に違反しているのかが、プロンプトを書き直す前に分かるように設計されている。

Meta — メタ情報

Version v0.3.0 — Pre-release(v1.0.0 は community adoption 後)
Last updated 2025-12-04
Authoritative version English(STANDARDS.md)。日本語版はコミュニティ翻訳。
Original editor Takaho Hatanaka(2024)
Synthesized from OpenAI / Anthropic / Google の公開ガイド + LangChain コミュニティ実践
Repository github.com/taka4rest/prompt-as-code
Spec document STANDARDS.md

まず読むことから。議論と改善提案も歓迎。

本仕様は living standard として運用されており、GitHub Issues / Pull Request を通じて誰でも参加できます。翻訳の追加、アンチパターンの報告、新しいパターンの提案など、形式を問わず受けつけています。

Read STANDARDS.md → Open Issues → Contact →