SharePointリストのGetTableエラーを解決する方法

やる気をもってPower AutomateとSharePointを組み合わせてみたものの、なぜか特定のリストテーブルだけエラーになってしまうと焦りますよね。私も以前、同僚と共同でシステムを構築した際に、思わぬ列設定が原因で止まってしまった経験があります。動作しない理由が一見わかりにくいぶん、見つけたときは「なんだ、こんなことか」と思いつつ、そこにたどり着くまでに苦労しました。このページでは、私が同じような状況で苦闘した実体験を交えながら、うまくいかない原因や対処方法を、できるだけわかりやすく解説していきます。

SharePointリストの特定テーブル「GetTable」エラーの概要

エラーの原因を探るとき、まずはどのようなメッセージが出ているのかを正確に把握することが重要です。今回のケースでは「The required field ‘Client’ data type is not supported」というメッセージが表示されます。つまり、Clientという列またはフィールドに何らかの非サポートな設定があり、それがPower Automateの「GetTable」アクションで弾かれている可能性が高いと推測できます。

エラーの具体的な内容

Power Automateフロー中で「GetTable」を呼び出した際、以下のようなメッセージが表示されるようです。

Failed to retrieve dynamic outputs. As a result, this operation's outputs might not be visible in subsequent actions.
Error details: The dynamic operation request to API 'sharepointonline' operation 'GetTable' failed with status code 'BadRequest'.
This may indicate invalid input parameters.
Error response: {
  "status": 400,
  "message": "The required field \"Client\" data type is not supported\r\nclientRequestId: 7ffcb686-a39e-44e4-88ed-6018495f261f\r\nserviceRequestId: 7ffcb686-a39e-44e4-88ed-6018495f261f"
}

上記のメッセージを見ると、どうやら「Client」列やそのデータ型に原因があることはほぼ間違いありません。この段階で注目すべきは、その列がどのような型で設定されているかという部分です。

権限周りの考慮

今回のケースでは、すでに該当テーブルに対する編集権限は付与されているとのことですが、SharePointでは列ごとに特殊な権限が設定されていることはあまり多くありません。しかし、リストやライブラリ全体に対する権限が正しくても、一部の列にパラメーター設定がある場合、Power Automateに認識されない場合もあります。権限というよりはデータ型や列の設定が一番のネックになりやすいです。

複合参照フィールドや外部参照型

「複合参照型」とは、ユーザー/グループ列のように内部的には複数の値を持っていたり、外部システムを参照している可能性があるフィールドを指します。たとえば、Person or Group型の列ではIDや表示名など、複数の属性をまとめて持っています。同様にLookup列やManaged Metadata列、外部リストを参照する列なども要注意です。これらはPower Automateが直接取得しようとすると、型の違いからうまくいかないことが多いです。

エラーの原因と対策方法

ここでは、代表的な原因とその対処方法を整理します。ただし、すべてのケースに当てはまるわけではありませんので、あくまでヒントの一つとしてご覧ください。

原因1: Client列のデータ型がPower Automate非サポート

SharePointでは様々な列タイプが利用可能ですが、Power Automateが取り扱えるデータ型に制限があります。とりわけUser/Group列や外部参照列などは、実装方法によっては非対応として扱われることがあります。

外部データソースを参照する列や、特殊なカスタム列はエラーが起きやすいです。

対策1.1: 単一行テキスト型に変更する

単純にClient列の値をテキストとして扱いたいだけであれば、SharePointの列設定を「単一行テキスト」に変更することが最もシンプルな解決策になります。ただし、すでにデータが大量に入っている場合は慎重に検証を行う必要があります。変更前と変更後で値の扱いに違いが出るかもしれないため、バックアップを取ってから試すと安心です。

対策1.2: 必要な情報だけをカスタム列にコピーする

参照情報が含まれる列を単一行テキスト型に変えるのが難しい場合、フローを実行する前に「文字列変換用の別の列」を用意し、そこに必要な情報だけをコピーしておく方法があります。Power Automateに渡すのはその単一行テキスト型の列にして、オリジナルの参照列は引き続きSharePointで使用するといった運用形態です。

原因2: Client列の名前と型設定の組み合わせによる不具合

SharePointリスト上の列名と実際のシステム内部名が異なる場合があります。たとえば、表示名は「クライアント」になっていても、内部名が「Client_x0020_Column」のように変形していることもよくあります。Power Automateがその内部名を正しく解釈できずにエラーが出るケースもあります。

列の内部名を確認し、できるだけシンプルかつわかりやすい名称にしておくとトラブルを減らせます。

対策2.1: SharePointリストの「内部名」を再確認

列の内部名はリストの設定画面から確認できます。列を新しく作成する際は、日本語の表示名とは別に、内部名がどう設定されるか注意してください。もし内部名が予期せぬ文字列になっている場合、一度列を削除して作り直すか、フロー内で正しい内部名を指定する必要があります。

対策2.2: API呼び出しのパラメーターを見直す

フローの「GetTable」アクションがどのようにテーブルを指定しているか、詳細設定を確認してください。特に高度なオプションやフィルターパラメーターなどを使っている場合、そのパラメーターが合致していない可能性もあります。クエリに誤った列名が含まれているとエラーになることがあります。

原因3: 取得したい列がそもそも必要ない

実はあまり使っていない列だったり、どうしても取得しなければならないほどの必須列ではない可能性もあります。フローで問題となっている列を取得範囲から除外できる場合は、それも有力な回避策になります。

対策3.1: フローのアクションから当該列をスキップする

テーブル全体でなく、特定の列だけ取得するように設定できるなら、そのようにアクションを組み直しても良いでしょう。ただし、Power AutomateのSharePointコネクタによっては「Get items」や「Get records」で一括取得するため、列の絞り込みが限定的なことがあります。アクションのカスタマイズ範囲を確認してください。

トラブルシューティングの表

具体的な例と対処法をまとめた表を用意しました。当てはまりそうな箇所をチェックしてみてください。

エラー内容 想定される原因 解決策
「The required field ‘Client’ data type is not supported」と表示される Client列が外部参照や複合型などの非サポートデータ型 列のデータ型を単一行テキストに変更
もしくは必要部分のみを別列にコピー
列名を正しく指定しているのにエラーが出る 実際の内部名が異なる可能性
列の特殊文字やスペース混在
SharePointリスト設定画面から内部名を再確認
正しい内部名で指定し直す
他の列は問題ないのに特定列だけ失敗する Power Automateがその列のメタデータを正しく取得できない カスタム列設定やリストテンプレートを見直す
フロー上で該当列の取得を除外

実際の修正手順

ここでは例として「Client」という外部参照列を、単一行テキストに直すケースを想定しています。操作の流れは概ね以下のとおりです。

1. SharePointリスト設定の確認

リストの設定にアクセスし、「列の設定」を開きます。該当する「Client」列のリンクをクリックして詳細を確認します。もし「外部データ」や「ユーザー/グループ」型、あるいは「参照列」など特殊な指定になっていれば、単一行テキストへ変更を検討します。

2. データのバックアップ

列の型を変更すると、値の扱い方が変わるためデータが失われる可能性があります。リスト全体をエクスポートするか、Power AutomateやExcelなどを用いてバックアップを取っておくと安心です。万が一のときも巻き戻しができます。

3. 型の変更とフローの修正

列を単一行テキストへ変更した後、Power Automateフロー側の「Get items」もしくは「GetTable」アクションの再設定を行います。列名やクエリの内容も合わせて確認しましょう。もし手動で列のマッピングをしている場合は、該当する列の参照先が変わっていないかチェックが必要です。

4. テストと動作確認

フローを手動またはトリガーによって実行し、エラーが解消されたかを確認します。以前取得できなかった列の値が正常に取得・表示されているかも重要なチェックポイントです。

私は、同じようにユーザー/グループ列を想定外に使っていたせいで、フローが急に止まったことがあります。外部要素が絡むと何が起きるか分からないので、なるべく単純な形式を使うのが一番ですね。

エラー回避のために覚えておきたい工夫

Power AutomateとSharePointリストを組み合わせる際、運用を円滑にする工夫はいくつかあります。ここでは特に重要と思われるポイントを紹介します。

列名はなるべく英数字やアンダースコアを使う

日本語の列名自体は悪くありませんが、内部名を確認したときに文字化けやスペースのエンコード(_x0020_など)が発生しやすいです。極力シンプルな英数字やアンダースコアだけを使うと、フロー作成時にトラブルが減ります。

大きなリストでは列数を絞る

非常に大きなリストで、しかも多くの列がある場合、フローの動作が遅くなるだけでなく、想定外のエラーを引き起こしやすいです。必要最低限の列だけを残し、不要な列は削除または別のリストへ切り出すことも検討しましょう。

定期的に構成レビューを実施

プロジェクトが進むにつれて、新しい列が増えたり、列の型を変えたくなることがよくあります。これらの変更がフローの不具合に直結するケースは少なくありません。定期的にフローとリストの構成をレビューし、問題が起きそうな列を早めに手を打つと大きなトラブル回避につながります。

私は「とりあえず列を追加しちゃおう」という運用を続けた結果、リストが膨れ上がってフローが複雑化し、どこを直せばいいのか分からなくなった苦い経験があります。定期的な棚卸しは大事ですね。

Power Automate Communityなど外部リソースの活用

もし今回ご紹介した方法を試してもうまくいかない場合、Microsoftの公式フォーラムやコミュニティサイトを活用することをおすすめします。スクリーンショットやエラーコード、テーブル構成などを一緒に載せることで、より的確なアドバイスが得やすいです。

具体的な投稿内容の例

問題を投稿する際に書いておくと良いポイントを簡単にまとめます。スクリーンショットはもちろん、可能ならエラーとなったJSONコード全体を共有すると状況が伝わりやすいです。

投稿例のコードスニペット

{
  "status": 400,
  "message": "The required field \"Client\" data type is not supported\r\nclientRequestId: 7ffcb686-a39e-44e4-88ed-6018495f261f\r\nserviceRequestId: 7ffcb686-a39e-44e4-88ed-6018495f261f"
}

このように、具体的なエラーメッセージを含めて質問することで、「この列はこういう設定になっているかもしれないよ」といった助言を受けられることが多いです。

実体験から得たTips

私は以前、クライアント名を管理する列をユーザー/グループ型で作成していました。これにより、顧客担当者の名前やメールアドレスをひとまとめに管理できて便利だった反面、フローを組んで自動化しようとしたときに全く動作しませんでした。結局、その列をテキスト列に分け、担当者名とメールを別々に管理する形に切り替えたところ、問題なくフローが動いたことがあります。最終的には運用を分けることで、むしろ確認がしやすくなりました。

切り分けを行うことでフローもスッキリし、どの列がどの情報を担当するのか分かりやすくなりました。

まとめ

今回のエラーは「Client」列がPower Automateにとって非サポートのデータ型であることが主な原因と考えられます。エラーを解決するには、単一行テキスト型や数値型といった汎用的な型を用いるか、別の列を用意してそこに変換後の値を格納する方法などが実践的です。列名の内部名にも注意しつつ、フロー側の設定を見直していけば多くの場合解決に近づけるでしょう。もしそれでも解決しない場合は、コミュニティやフォーラムの助けを借りるのがおすすめです。

不具合の原因が分かったときは「あ、これだけか!」と思うことがほとんどです。最初に気付けないだけで、答えは割とシンプルなことが多いです。もし同じように困っている方がいれば、この記事が少しでもお役に立てれば嬉しいです。

コメント

コメントする