AIデータ基盤 2026｜YAMLを活用してAIワークフローを効率的に管理する方法

AIエージェント時代に求められる設定管理とは

アシム（Media Fusion / エンジニア）
こんにちは！ネパール出身のアシム・レグミと申します。
Media Fusion Co., Ltd.でJava Backendエンジニアとして勤務しています。
データ基盤やAI時代のデータ活用に関心を持ち、データ技術に関する実務で得た知見や経験をご紹介していきたいと考えています。

「AIデータ基盤 2026」シリーズ
▼第1回：なぜMarkdownがAI活用の基盤となるのか？
― LLMやRAGで成果を出すための文書構造を理解する ―
▼第2回：YAMLを活用してAIワークフローを効率的に管理する方法（本記事）
― AIエージェント時代に求められる設定管理とは ―
▼第3回：Open Knowledge FormatでAI時代の知識基盤を構築する
― 再利用しやすいデータ管理の考え方と実践方法 ―

はじめに

第1回では、「人が読むために書かれた文書を、AIが正しく理解できる形に整えるのがMarkdownである」とご説明しました。

ただし、文書だけではAIの仕組みは動きません。複数の手順を組み合わせたワークフローに進むと、「設定」という別の情報が重要になります。

この段階で、多くの担当者が同じ壁にぶつかります。

設定を誰がいつ変更したのか分からない

同じ指示文（プロンプト）が複数の画面にコピーされている

検証環境と本番環境で動きが違う

原因は共通しています。設定が画面の中だけに存在し、記録も確認手段も残っていないからです。

1. なぜAI活用で「設定管理」が問題になるのか

チャットでの一往復なら、設定する項目はほとんどありません。しかし、社内文書を検索し、外部システムを呼び出して報告書を作成するワークフローでは、設定項目が一気に増えます。

使用するモデルと、そのバージョン

生成の温度（temperature）や、出力の最大長

AIに与える役割や制約を書いた指示文（プロンプト）

検索対象とする知識ベースと、モデルに渡す件数

多くのAI基盤では、これらを画面上で入力できます。手軽な半面、業務で本格的に使い始めた途端に弱点になります。

履歴が残らない：品質が下がった変更を、安心して元に戻せない

誰が変えたか分からない：原因の調査が推測になる

別の環境に移せない：本番環境へ、同じ設定を手作業で入れ直すことになる

事前に確認できない：反映前に、同僚が内容を確認できない

解決策は、設定を「画面への入力」ではなく「ファイル」として扱うことです。その用途で最も広く使われている形式が、YAMLです。

2. YAMLとは何か、Markdownとどう違うのか

YAMLは、Clark Evans氏らによって設計され、1.0仕様は2004年初めに公開されました。名称は「YAML Ain't Markup Language」の略で、設計目標の第一に「人間が読みやすいこと」が掲げられています。

MarkdownとYAMLは、どちらも文字だけで書ける簡素な形式のため混同されがちです。しかし、想定している読み手が異なります。

項目	Markdown	YAML
主な読み手	人	システム
表現するもの	意味の階層（見出し・段落）	データの構造（項目と値）
向いている内容	説明・手順書・ナレッジ	設定値・定義・手順
AI活用での役割	RAGの元データ	ワークフローやエージェントの定義

YAMLは、「項目名: 値」、階層を表す字下げ（インデント）、並びを表す「-」の3つで構造を表します。

model: gpt-4o 
temperature: 0.2 
retrieval: 
  index: product-manual 
  top_k: 5 
tools: 
  - web_search 
  - internal_database

字下げには半角スペースを使う。タブ文字は使えない

同じ階層では、スペースの数をそろえる

3. AIワークフローでYAMLが使われている場面

指示文とワークフローを、ファイルとして管理する

マイクロソフトのSemantic Kernelでは、指示文をプログラムに埋め込まず、YAMLで定義します。指示文の本文、差し込む変数、実行時のモデル設定をまとめて記述できます。

name: SummarizeReport 
template: | 
  次の報告書を3つの箇条書きで、200文字以内に要約してください。 
  報告書: {{input}} 
execution_settings: 
  default: 
    temperature: 0.3

AIアプリ開発基盤のDifyでは、アプリ全体をYAML形式のDSLファイルとして書き出し、別の環境に読み込めます。外部ツールのAPIキーは、安全のため含まれません。

情報システム部門は、すでにYAMLを使っている

YAMLは、AIとともに登場した新しい形式ではありません。情報システム部門が日常的に運用しているツールで、標準の設定形式として使われています。

分野	代表的なツール	YAMLで定義する内容
ビルド・リリースの自動化	GitHub Actions、GitLab CI	実行する手順と、実行する条件
コンテナ運用	Docker Compose、Kubernetes	動かすサービスと、割り当てる資源
サーバー構成管理	Ansible	各サーバーのあるべき状態
AIアプリ開発基盤	Dify、Semantic Kernel	ワークフローの定義と指示文

CIやKubernetesの設定で培った確認の習慣は、AIワークフローの設定にそのまま活かせます。

4. よくある落とし穴と、その防ぎ方

値の種類が勝手に変わる

最も多い落とし穴で、「ノルウェー問題」として知られています。

「country: NO」は、文字の「NO」ではなく false になる（no、yes、on、off も同様）

「version: 1.10」は、数値の 1.1 になる

「code: 0755」は、8進数の数値として読まれることがある

防ぎ方は、たった1つの習慣です。文字として扱いたい値は、引用符で囲みます。

country: "NO" 
version: "1.10" 
code: "0755"

そのほか注意したい点

字下げにタブ文字は使えず、不ぞろいだと、どの設定がどこに属するかが変わってしまう

複数行の指示文には「|」を使う。「>」は改行をつなげて1行にまとめてしまう

APIキーやパスワードはYAMLに書かず、環境変数や秘密情報の管理サービスを参照する

取り入れる価値がある検証ツール

上記の落とし穴は、反映前に自動で見つけられます。次の4つは、いずれもオープンソースです。

ツール名	種類	できること
yamllint	文法チェック	文法の誤り、字下げの間違い、書き方の不統一を検出する
check-jsonschema	項目の検証	JSON Schemaに沿って、項目名や値の種類の誤りを検出する
Red Hat YAML拡張（VS Code）	編集支援	入力補完を行い、書きながら誤りを表示する
Prettier	整形	書式をそろえ、体裁だけの差分が出ないようにする