ClaudeでPower Automateの式エラーを直す — flow定義JSONの読み方

Power Automateのクラウドフローで式エラーが出たら、ソリューションとして書き出したフロー定義(JSON)と、失敗した実行の入力値をセットでClaude Codeに渡します。定義だけ、あるいはエラー文だけでは、式がどんなデータを受け取って落ちたのかが分からないためです。

この記事は、式エラーの切り分けから、定義の取り出し、Claude Codeへの渡し方、直した定義を戻すところまでを順に示します。

式エラーは「保存時」と「実行時」で直し方が変わる

最初に見るのはエラーコードです。クラウドフローの式まわりのエラーは、出る場面で二つに分かれます。

実行時エラーが起きるのは、式が変数やトリガー本文、アクション出力のような動的な値を使うときだけです。int('abc') や div(100, 0) のように定数だけの式は、保存時に InvalidTemplate として捕まります。

保存時のエラーは定義の文字列を読めば決まることが多く、Claude Codeの得意な領域です。実行時のエラーは「そのときの値」が要るので、定義だけ渡しても原因を言い当てられません。この区別が、依頼文の書き方を決めます。

手順 — 定義を取り出して失敗アクションを渡す

1. ソリューションを書き出し、フロー定義を取り出す

ソリューション対応のクラウドフローは、フロー詳細ページからは書き出せません。ソリューションの画面でエクスポートします。書き出しの前に「すべての変更を公開」を選ぶと、公開済みの内容だけでなく最新の編集も含められます。アンマネージドのソリューションは、公開済みのコンポーネントしか書き出されないためです。

ダウンロードしたZIPのWorkflowsフォルダーに、フローごとのJSONファイルがあります。2022年2月以降の書き出しは複数行に整形されたJSONで、以前の1行に詰めた形式より差分が読みやすくなっています。

フォルダーに展開してGitで管理する手順は、pac solutionでソリューションを編集する記事に書いています。展開後にコミットしておけば、あとの差分はすべてClaude Codeの編集分になります。YAML形式のソース管理フォルダーでは、クラウドフローは modernflows/ フォルダーに置かれます。

2. 失敗アクションの式と入力値をテキストで控える

実行時エラーなら、フローの実行履歴(28日分)から失敗した実行の日付を選び、赤い感嘆符の付いた手順を開きます。右ペインにエラーの詳細と対処が出ます。失敗アクションを開くと、評価された式と入力値も確認できます。

控えた入力値は、そのまま貼らずに顧客名やメールアドレスをダミーに置き換えます。Claude Codeに渡した内容は会話の記録に残るので、実データを含めない形にしておくほうが安全です。

3. 依頼文には「どのアクションの何が落ちたか」を書く

Claude Codeには、ファイル全体の見直しではなく、失敗した1か所を調べさせます。たとえば次のように書きます。

flows/Workflows/ 配下の発注通知フロー(JSON)で、Compose_件名 が
ExpressionEvaluationFailed で失敗しました。
失敗時の入力値は次のとおりです(顧客名はダミーに置換済み)。
- Get_item の出力: 空(該当レコードなし)
定義を読んで、式のどこが null を受けて落ちたかを説明し、
null でも落ちない形に直してください。
直す範囲は Compose_件名 の式だけにしてください。

Claude Codeは、アクション名で定義を検索して該当箇所を読み、式を直します。こうした依頼の骨格は、Claude Codeの一般的な「エラーを共有して、原因と直し方を聞き、直させる」流れそのままです。再現手順や、毎回起きるのか断続的なのかを添えるほど絞り込みやすくなります。

4. 式を一覧にしてから、失敗アクションとの関係を読ませる

失敗アクションの式だけを見ても、原因が上流にあることは珍しくありません。式が参照している前のアクションが、そもそも空の値を返している場合です。そこで、先に定義内の式を一覧にさせると、参照の連鎖が追えます。

jq -r '.. | strings | select(startswith("@") or contains("@{"))' \
  <フローのJSONファイル>

<フローのJSONファイル> には、手順1で見つけたファイルを入れます。出てきた式のうち、失敗アクションが outputs('...') や body('...') で名指ししているアクションを辿り、その式も読ませます。依頼文には「失敗アクションが参照している前段のアクションを、式の参照をたどって列挙して」と書けば足ります。

定義には各アクションの runAfter も入っています。前段が失敗・スキップされても後段が走る設定になっていると、空の出力を後段の式が受けて落ちます。実行後設定(Run after)は、アクションが失敗・タイムアウト・スキップ・成功したときに次へ進むかどうかを決める仕組みです。Claude Codeには、失敗アクションの runAfter が何を許しているかも一緒に読ませます。

原因が上流にあると分かったら、直す場所の候補を二つに分けて報告させます。前段の出力が空になる理由を直すか、後段の式を空でも落ちない形に直すかです。前者はフローの流れを変えるので影響が広く、後者は式1か所で済みます。どちらを採るかは、フローを運用している人が決めます。報告を受けてから、直す範囲を一言で指定し直すと、編集が意図しない場所へ広がりません。

定義のなかで式エラーになりやすい箇所

定義JSONでは、式は文字列として入っています。たとえば、Composeアクションの入力が次のような形です(アクション名と式は説明用に作った架空の例です)。

"Compose_件名": {
  "type": "Compose",
  "inputs": "注文通知: @{outputs('Get item')?['body/title']}",
  "runAfter": { "Get_item": [ "Succeeded" ] }
}

この1か所に、読む価値のある点が二つあります。

• 式がテキストの途中に入るときは @{...} の波括弧が必要です。テキストと混ぜない式は @outputs(...) だけで足ります
• アクション名の参照は、スペースではなくアンダースコアを使い、大文字小文字も区別します。例の Get item は Get_item に直すのが正解です

Claude Codeに点検させるときは、次の表の観点を依頼文に入れておくと取りこぼしが減ります。

最後の行だけは、Claude Codeに見つけさせる価値が大きい項目です。目で見て気づけない文字でも、ファイルを検索すれば拾えます。依頼文には「式に含まれるASCII以外の文字を列挙して」と書けます。

Claude Codeに向かないエラー

式ではないエラーは、定義を直しても解決しません。切り分けの目安を挙げます。

• 認証エラー(Unauthorized や401・403): 接続を更新して、失敗した実行を再送信します
• Bad request や Not found(400・404): アクションの設定が合っていないので、設定を直してから再送信します
• 500・502: 一時的な失敗なので、再送信で様子を見ます
• 接続が切れている(InvalidConnection): ソリューションを別環境に取り込んだ場合など、接続が存在しないことが原因です。定義の式は関係しません

デスクトップフローのエラーは、クラウドフローとは別のリファレンスで扱われています。RPAフローの移行は、Power Automate Desktopのフローをスクリプトに置き換える記事が扱っています。

作業の境界をCLAUDE.mdに書いておく

定義JSONは、直し方を間違えるとソリューションの取り込みで別のエラーを生みます。たとえば、アクション名を変えると、そのアクションを参照する式も outputs('Old_Name') から outputs('New_Name') へ直す必要があります。手で編集した定義でキーが重複すると、DuplicateActionName のエラーになります。

編集の範囲と禁止事項は、先にプロジェクトのCLAUDE.mdに書いておきます。

## Power Automateのフロー定義
- 編集してよいのは solution-src/ 配下の該当フローJSONだけ
- 直す前に、失敗アクション名と、直す式を一覧で報告する
- アクション名は変えない(変えるなら参照している式もすべて直す)
- 式の変更後は、JSONとして正しいか jq empty <ファイル> で確かめる
- pac solution import / delete / publish は実行しない

jq empty はJSONの構文だけを検査します。式が実行時に通るかどうかまでは分かりません。直した定義が正しいかは、環境に取り込んだあと、失敗した実行を再送信して確かめます。

環境に接続するコマンドを止める権限ルールの書き方は、pac solutionの記事にまとめています。

定義を読ませる方法とCopilotの使い分け

Power Automateのデザイナーには、エラーの要約と解決策を示す「Copilotでトラブルシューティング」があります。新しいデザイナーを有効にしているときに使えます。

どちらも実行履歴のエラーから始められますが、役割は違います。

1本の失敗だけを直すなら、デザイナー上のCopilotで足ります。同じ書き方の式が複数のフローに散らばっているとき、定義JSONをまとめて検索できるClaude Code側が効きます。

まとめ

式エラーは、保存時の InvalidTemplate なら定義を読めば直ることが多く、実行時の ExpressionEvaluationFailed なら失敗時の入力値が要ります。Claude Codeに渡す材料は、この区別で決まります。

直す範囲を失敗アクション1か所に絞ることと、取り込みは人が行うことの二つを守ると、定義の編集で別の障害を起こすおそれを小さくできます。CLAUDE.mdや権限ルールの考え方そのものはClaude Code完全ガイドにまとまっています。