コルネの進捗や備忘録が記されたなにか

進捗や成果物や備忘録てきななにかを雑に更新していきます。

Power Appsで住所入力フォームを作成する

はじめに

Power Appsで簡単にかつ、表記揺れ少なく住所の登録を行うとしたらどういう方法があるかな?
とちょっと考えてみたので、いくつか案を記載します。

もっといい案などあればコメント等していただけると嬉しいです!

入力想定

入力想定としてはこんな感じ。

よくある郵便番号を入力したら、その結果をもとに都道府県、市区町村、町名までの入力を補完してくれるやつです。

郵便番号から住所を検索する

Bing Mapsコネクタの利用

Power PlatformのコネクタにはBing Mapsコネクタがあります。

learn.microsoft.com

こちらは標準コネクタなので追加のライセンスなしで利用することができます。

ただし利用にはAPI Keyが必要になります。

API Keyの発行はこちらで行うことができます。

www.bingmapsportal.com

とりあえず開発目的で試してみるだけでしたら無料で発行することが可能です。

今回郵便番号から検索を行いたいので「住所で場所を取得する(GetLocationByAddress)」を利用します。

例えば以下のように取得することできますね。

BingMaps.GetLocationByAddress({postalCode:Form1.Updates.部屋番号,countryRegion:"JP"})

今回欲しい(と思われる)情報はaddressにあるので以下のように取得します。

UpdateContext({getAddress: BingMaps.GetLocationByAddress({postalCode:Form1.Updates.部屋番号,countryRegion:"JP"}).address})

とりあえず日本マイクロソフト本社がある住所で試してみました。

その結果はこちらです。

うーーん。。。

一応参考までに.addressを指定せずに生の値をそのまま取得した場合はこちらになります。

欲しい情報とれてないですねー。。。

ということで、このコネクタを利用することでは今回の目的は達成できなさそうです。

ちなみにこれ、日本だからできないのかな?と思いましたが、USでもなんか上手く動いてないっぽい?

国コードを"US"に変更して、Microsoft US本社の住所で検索してみます。

UpdateContext({getAddress: BingMaps.GetLocationByAddress({postalCode:Form1.Updates.部屋番号,countryRegion:"US"})})

結果はこちら

うーん。残念!

ちなみにこちらのAPIの元になっていると思われるこちらのAPIを実行した場合の結果も参考までに以下で載せておきます。

learn.microsoft.com

日本Microsoftの郵便番号で検索

url

https://dev.virtualearth.net/REST/v1/Locations/JP/1080075?o=json&key={BingMapsKey} 

Result

{
  "authenticationResultCode": "ValidCredentials",
  "brandLogoUri": "https://dev.virtualearth.net/Branding/logo_powered_by.png",
  "copyright": "Copyright © 2024 Microsoft and its suppliers. All rights reserved. This API cannot be accessed and the content and any results may not be used, reproduced or transmitted in any manner without express written permission from Microsoft Corporation.",
  "resourceSets": [
    {
      "estimatedTotal": 1,
      "resources": [
        {
          "__type": "Location:http://schemas.microsoft.com/search/local/ws/rest/v1",
          "bbox": [
            35.623119354248047,
            139.7376708984375,
            35.6387825012207,
            139.7593994140625
          ],
          "name": "108-0075, Japan",
          "point": {
            "type": "Point",
            "coordinates": [
              35.63023758,
              139.74839783
            ]
          },
          "address": {
            "countryRegion": "Japan",
            "formattedAddress": "108-0075, Japan",
            "locality": "Tokyo",
            "postalCode": "108-0075"
          },
          "confidence": "High",
          "entityType": "Postcode1",
          "geocodePoints": [
            {
              "type": "Point",
              "coordinates": [
                35.63023758,
                139.74839783
              ],
              "calculationMethod": "Rooftop",
              "usageTypes": [
                "Display"
              ]
            }
          ],
          "matchCodes": [
            "Good"
          ]
        }
      ]
    }
  ],
  "statusCode": 200,
  "statusDescription": "OK",
  "traceId": "26207454a1105398697042f88fe1c17b|PUS000DE1E|0.0.0.1|Ref A: 112EC9BA7E5642DAAAC907663DE1764B Ref B: SEL20EDGE0205 Ref C: 2024-01-30T17:47:30Z"
}

US Microsoftの郵便番号で検索

url

http://dev.virtualearth.net/REST/v1/Locations/US/98052?o=json&key={BingMapsKey}

Result

{
  "authenticationResultCode": "ValidCredentials",
  "brandLogoUri": "https://dev.virtualearth.net/Branding/logo_powered_by.png",
  "copyright": "Copyright © 2024 Microsoft and its suppliers. All rights reserved. This API cannot be accessed and the content and any results may not be used, reproduced or transmitted in any manner without express written permission from Microsoft Corporation.",
  "resourceSets": [
    {
      "estimatedTotal": 1,
      "resources": [
        {
          "__type": "Location:http://schemas.microsoft.com/search/local/ws/rest/v1",
          "bbox": [
            47.626979827880859,
            -122.16493225097656,
            47.734012603759766,
            -122.07723236083984
          ],
          "name": "98052, WA",
          "point": {
            "type": "Point",
            "coordinates": [
              47.67053604,
              -122.12073517
            ]
          },
          "address": {
            "adminDistrict": "WA",
            "adminDistrict2": "King County",
            "countryRegion": "United States",
            "formattedAddress": "98052, WA",
            "locality": "Redmond",
            "postalCode": "98052"
          },
          "confidence": "High",
          "entityType": "Postcode1",
          "geocodePoints": [
            {
              "type": "Point",
              "coordinates": [
                47.67053604,
                -122.12073517
              ],
              "calculationMethod": "Rooftop",
              "usageTypes": [
                "Display"
              ]
            }
          ],
          "matchCodes": [
            "Good"
          ]
        }
      ]
    }
  ],
  "statusCode": 200,
  "statusDescription": "OK",
  "traceId": "a455e74cba328865371503122ff44e28|PUS000DE25|0.0.0.1|Ref A: 24130242C72E483CACE4E5068CCC4967 Ref B: SEL20EDGE0405 Ref C: 2024-01-30T17:51:47Z"
}

仮にこちらのAPIを用いてカスタムコネクタを自作しても、日本語の住所は取れなさそうですので日本向けに利用することを考えると、ちょっと微妙ですかね。。。

郵便番号APIサービスからカスタムコネクタを作成する

郵便番号検索APIサービスを利用してカスタムコネクタを作成し、それを用いて郵便番号から住所の検索を行ってみます。

今回は"zipcloud"というサービスを利用してみようと思います。

zipcloud.ibsnet.co.jp

選定理由は無料で使えて、またリクエストやレスポンスがシンプル、欲しい情報が取れそう。というだけですので、もちろん他にもいいサービスはあるとは思います。
これじゃなきゃダメってわけじゃないですよ。

カスタムコネクタを作成する

  1. 「カスタムコネクタの新規作成」より「一から作成」を選択します。
  2. 適当なコネクタ名を入力します。
  3. ドキュメントより、ベースとなるURLは以下のように記載されています。

    ベースとなるURLは以下になります。
    https://zipcloud.ibsnet.co.jp/api/search
    このURLにリクエストパラメータを加え、リクエストを行います。

  4. ということで以下のように設定します。
  5. こちらのAPIは認証情報を特に必要としないので、続いて定義を作成します。

  6. 最後に接続情報を作成した後にテストをしましょう。

アプリから呼び出す

あとは、こちらのコネクタをアプリに追加して使ってみます。

UpdateContext({searchAddress: zipcloud.SearchAddress({zipcode: Form1.Updates.郵便番号}).results})

結果はこんな感じ

いい感じに取得できてますねー

おまけ

Microsoft Listには列の種類で「場所」というものがあります。

ここに郵便番号を入力すると、候補がでてきます。

どれ選べばいいんだ...?

まず上の北品川を選んだ場合

北品川区ってどこですか...?というか日本Microsoftは品川区にあった...?

続いて港南

港南は区ではないですね。おしい。

続いて最後

ダメな気がしましたがダメですね!

ちなみにこちらPower Appsから更新することはできません。

おわりに

現状Power Appsで日本の住所検索を行う場合は外部APIを利用するのが一番欲しい結果が得られそうですね。

【Power Apps】Preview機能で追加されたユーザー定義関数(UDF)を試してみる

はじめに

Power AppsのPreview機能にユーザー定義関数(UDF)が追加されました!

今回はこちらのユーザー定義関数について記載しています。

なおまだPreview機能ですので、今後変更になる可能性があります。

前提条件

こちらのユーザー定義関数を利用するには、Power Appsの作成バージョンが"3.24013.14"以上である必要があります。

設定 > サポート > 作成バージョン
より、変更が可能です。

また、ユーザー定義関数を利用するためには、"新しい分析エンジン"も有効化する必要があります。

こちらは
設定 > 近日公開の機能 > 試験段階
より、有効化することができます。

"ユーザー定義関数"も同様に
設定 > 近日公開の機能 > 試験段階
から有効化できます。

有効化後アプリを再読み込みする必要があります。

ユーザー定義関数の使い方

ユーザー定義の作成方法

ユーザー定義関数は"App"の Formulas に記載します。

関数を作成する際は、以下のような構文で作成します。

<関数名>(<パラメータ名>:<パラメータの型>):<関数の型> = ;

実際の例を見てもらった方がわかりやすいかもです。

ということで以下DAX関数にある PDURATION 関数を作成します。

learn.microsoft.com

この関数は以下のような財務関数です。

投資が指定された値に到達するまでに必要な期間数を返します。

早速作成してみると、以下のようになります。

PDURATION(rate:Number, pv:Number, fv:Number):Number = (Log(fv) - Log(pv)) / Log(1 + rate);

式の最後にはセミコロン";"が必要な点に注意してください。

"型"に指定可能な型の種類は現在10種類あります。

テーブルやレコードは指定できないようですね。

ユーザー定義関数を利用する

作成したユーザー定義関数を呼び出す際は以下のように利用します。

PDURATION(0.025, 2000, 2200)

通常の関数利用と同じですね。

Tips

複数のユーザー定義関数の作成

ユーザー定義関数は複数作成することも可能です。

複数のユーザー定義関数を作成したい場合は、セミコロン区切りで作成してあげればよいです。

"UntypedObject"に値を渡す

"UntypedObject" なパラメータに対して値を渡したい場合は ParseJSON 関数を利用します。

learn.microsoft.com

例えば以下のようなユーザー定義関数を作成したとします。

UntypedObject(val:UntypedObject):Number = val;

パラメータの "val" を "UntypedObject" に指定しています。

この関数に対して、普通に(?)値を渡すと以下のような型エラーが発生します。

現在Power AppsでUntypedObject型の値を作成するには ParseJSON 関数を利用する必要があります。

これで "UntypedObject" に対して値を渡すことができるようになります。

Table型のデータを渡す

先ほどの "UntypedObject" を活用すればテーブルも渡すことができます。

以下のような式を記載することで、"UntypedObject" であるが中身としてはテーブル形式のデータを作成することができます。

ParseJSON("[3, 2, 6, 6, 4, 5]")

このようにすればテーブル型のデータもユーザー定義関数に含めることができます。

例えば以下のような中央値を求めるユーザー定義関数をみてみましょう。

Median(values:UntypedObject):Number = 
Index(
    Sort(
        ForAll(
            Table(values),
            Int(ThisRecord.Value)
        ),
        Value
    ),
    RoundUp(CountRows(Table(values)) / 2, 0)
).Value;

上記のように受け取った値を Table 関数を利用して、Table型に変換してあげればTableデータも利用できるようになります。

ただし、これで型変換を行っても中の値は "UntypedObject" のままなので注意してください。
この制限があるので、Sortを行う前にForAllでテーブル内の値に対して型を明示的に設定しているわけです。

できないこと

式には動作関数を含めることができません。

例えば Patch 関数や Collect 関数などは設定できないということですね。

カスタムコンポーネントとの違い

Power Appsでは以前からカスタムコンポーネントでプロパティの型に関数を指定することでカスタム関数を作成することができました。

learn.microsoft.com

カスタムコンポーネントってなに?という方は去年の資料なのでちょっと古いですが、M365VMで登壇した資料をみてみてください。

www.docswell.com

ユーザー定義関数とカスタムコンポーネントの違いを書き出すと以下ですかね。

データ型

パラメータに利用できるデータ型の種類に差異があります。

ユーザー定義関数

カスタムコンポーネント

ユーザー定義関数は返される値のデータ型とパラメータに設定可能なデータ型が同じなのに対し、カスタムコンポーネントは異なります。("画面"が増えてる)

ユーザー定義関数

カスタムコンポーネント

パラメータの設定方法

カスタムコンポーネントでは以下のようにパラメータをGUI操作で1つずつ設定していきます。

たいしてユーザー定義関数は式を記載するだけで簡単に設定できます。

まぁ、カスタムコンポーネントの設定方法の方が後から見たときに比較的わかりやすい。という見方もできますけどね。

あとは、カスタムコンポーネントだとパラメータの説明を記載でき、また必須かオプションかも設定が可能です。
対してユーザー定義関数はこれらができません。(まだ実装されていないのか、私がやり方理解できていないだけなのかわかりませんが。。。)

カスタム関数の共有

カスタムコンポーネントコンポーネントを公開して共有すれば、そのコンポーネントの中身を再開発しなくとも、またコンポーネントの中身の処理を理解していなくとも、他のユーザーも利用することができます。

対して、ユーザー定義関数はそもそも共有する術がありません。

共有するとすれば、作成したカスタム関数をコピペで共有するぐらいですね。

おわりに

こちらの機能はPreview機能なので、本番環境で利用する際は自己責任になりますのでご注意ください。

(2024/01/14)Power AppsでSharePoint リスト(Microsoft リスト)の画像列を利用する場合の注意点

はじめに

SharePoint リスト(Microsoft リスト)の画像列の仕様がここ最近変更になりましたね。

変更内容に関してはこちらの記事で紹介していますので、まだ確認されていない方は確認してみてください。

koruneko.hatenablog.com

前の仕様に戻したい方はこちらを試してみてください。

koruneko.hatenablog.com

さて、今回はそんなSharePoint リストの画像列をPower Appsで利用する場合の注意点を追記します。

上記のブログで触れていることは再度は触れないのでご了承ください。

Power Appsからリストに画像を登録できないケースがある

リストの設定

以下のような3種の画像列を用意しました。

  1. 表示名と内部名が同じもの
  2. 日本語でフィールドを作成したもの
  3. 表示名と内部名が異なるもの
内部名 表示名
Image Image
画像 x753b__x50cf
Pic Picture

これらのフィールドに対してPower Appsから画像を登録してみます。

Power Appsから画像列に画像を登録する

さて、それでは画像の登録を行ってみます。

チェックアイコンを選択して SubmitForm を実行します。

SubmitForm(Form1)

その結果は以下のようになりました。

日本語で作成したフィールドだけ画像が登録されていないですね。

ちなみにPower Apps側でみた場合もこのような感じ。

画像列に登録した画像は添付ファイル列に紐づくことになりますが、添付ファイル列には画像ファイルは2枚しか登録されていないですね。

このように、現在(2024/01/14)日本語などの内部名に使用できない名前でフィールドを作成した場合、画像列に画像を登録できないようです。

モニターをみてみる

Power Appsのモニター機能を利用して処理を確認してみましょう。

Power Appsのモニター機能に関しては以前にこちらで紹介していますのでよろしければみてみてください。(後半あたり)

www.docswell.com

公式ドキュメントはこちら

learn.microsoft.com

さて、先ほどの処理(SubmitForm)をモニターでみてみると、1か所失敗している処理があることがわかります。

こちらの処理をみてみると、以下のような応答結果を確認することができます。

どうやら列を特定できてないようですね。

API Management経由で処理が呼ばれているので確かなことはわからないですが、他二つの呼び出し方法をみるに"OData__"で呼び出してるのがダメなんじゃないかな?

回避策

このように、現在(2024/01/14)日本語などの内部名に使用できない名前でフィールドを作成した場合、画像列に画像を登録できないようです。

現時点での回避策としては、フィールド作成時に内部名に使用できる文字列でフィールドを作成してもらって、あとで表示名を変更する。
ですかね。

回避って書いといてなんですが、リストを利用するのであればこのような問題なしにしても、上記のようなやり方でフィールドを作成するように癖をつけた方が良いです。

OData__~~みたいに記載されていても、後から見たとき何の列かわからなくなりますからね。

おわりに

最近色々なところでアップデートきていますが、製品間での整合性やこれまでできたことができなくなっている or 使いにくくなっている。ということがいくつか確認できていますね。(Power Appsに限った話ではなく)

このような不具合や要望は積極的にフィードバックをあげるようにしましょう。

最近ですとフィードバックの甲斐があって(?)、Power Appsの数式バーのサイズが可変に変更できるように戻りましたね。(新しいバージョンでの動作かな)

私もフィードバックちゃんとあげなきゃ。。。

Power Appsで月末の計算が簡単にできるようになりました!

はじめに

Power Fxに EDate 関数と EOMonth 関数が追加されました!

learn.microsoft.com

これによりPower Appsで簡単に月末の計算ができるようになりました。

Power Appsで月末を求める

これまでは

これまではPower Appsで月末を求めようとすると以下のような式で計算する必要がありました。

DateAdd(Date(Year(DatePicker1.SelectedDate), Month(DatePicker1.SelectedDate) + 1, 1), -1)

ちなみに月初めはこちらですね。

Date(Year(DatePicker1.SelectedDate), Month(DatePicker1.SelectedDate), 1)

これからは

しかしこれからはこんな式書かなくとも EOMonth 関数を利用して簡単に月末を求めることができるようになりました!

例えば対象の月の月末を求めたい場合は以下のようになりますね。

EOMonth(DatePicker1.SelectedDate, 0)

EOMonth 関数は第一引数に元となる日付を、第二引数に第一引数に加算する月の数を設定します。

なので対象の日付の月末を求めたい場合は上記のように

// "DatePicker1.SelectedDate"の月末
EOMonth(DatePicker1.SelectedDate, 0)

となり、3か月後の月末だと

// "DatePicker1.SelectedDate"の3か月後の月末だと
EOMonth(DatePicker1.SelectedDate, 3)

となり、5か月前の月末だと

// "DatePicker1.SelectedDate"の月末
EOMonth(DatePicker1.SelectedDate, -5)

となります。

簡単に月末を求められるようになりましたねー

EDate

同時に追加された EDate 関数も一応紹介しておきます。

こちらは第一引数に指定した日付に、第二引数で指定した月を加算した結果を返します。

これにより加算された結果は月末を超えない限りは日付の箇所は変更されません。
例えば、7月31日に1か月加算すると、6月30日になります。

EDate(Date(2024, 1, 31), 1)

上記に結果は "2024/02/29" となります。

EDate(Date(2024, 1, 31), 2)

上記に結果は "2024/03/31" となります。

EDate(Date(2024, 1, 31), 3)

上記に結果は "2024/04/30" となります。

EDate(Date(2024, 1, 31), 0)

上記に結果は "2024/01/31" となります。

EDate(Date(2024, 1, 31), -1)

上記に結果は "2023/12/31" となります。

EDate(Date(2024, 1, 30), 2)

上記に結果は "2024/03/30" となります。

EDate(Date(2024, 1, 30), 3)

上記に結果は "2024/04/30" となります。

ただPower Appsでの日付計算に慣れている方はここまでみて気づいたかもしれませんが、これ既存の DateAdd 関数で月を加算したときと同じ動作なんですよね。

DateAdd(Date(2024, 1, 31), 2, TimeUnit.Months)

EDate 関数に関しては、 DateAdd 関数との使い分けがいまいちわからなかったです。。。
どなたか知見のある方いたら、こういうことができるようになったよ!などご教示いただけると幸いです。

おまけ

最近の更新でPower Automate DesktopでもPower Fxを利用できるようになりました。

learn.microsoft.com

そして、 EOMonth 関数はデスクトップフローでも利用することができます。

つまり今回のアップデートにより、PADでも月末の計算が容易になったというわけです。

例えばこんなフローを作成します。

すると、以下のように月末を表示してくれる。というわけですね。

おわりに

Power Fxにはこの関数の他にもいくつか関数が追加されています。

気になった方は是非見てみてくださいねー

learn.microsoft.com

Power Platformのソリューションのインポート時に環境変数が常に表示され、編集できるようになりました

はじめに

Power Platformのソリューションのインポート時及びパイプラインのデプロイ時に、環境変数が表示され、また編集もできるようになりました!

powerapps.microsoft.com

これまではソリューション内で環境変数を利用していた場合、エクスポート前に環境変数の既定の値を削除しないとソリューションインポート時及びパイプラインでのデプロイ時に環境変数の値を変更することができませんでした。

パイプラインのお話でいうとこの前にJPPC2023でお話した資料のP.30がそのことについて触れていますね。

www.docswell.com

以前まではこのように環境変数の既定の値をつけたままマネージドソリューションとしてエクスポートしてしまうと、環境変数が変更しにくくて困る。っていう問題がありました。
(一応既定のソリューション内で無理矢理変更できないこともない)

これが今回のアプデで解消されたってわけですね。

この記事ではその動きを簡単にみていきます。

環境変数の更新

元のソリューションはこのようなオブジェクトを用意しました。

$"CurrentValue: {LookUp('Environment Variable Values', 'Environment Variable Definition'.'Schema Name' = "korune_CurrentValue", Value)}"
$"StayCurrentValue: {LookUp('Environment Variable Values', 'Environment Variable Definition'.'Schema Name' = "korune_StayCurrentValue", Value)}"

環境変数"CurrentValue"は「現在値」をソリューション内から削除して、環境変数"StayCurrentValue"は「現在値」をそのままにしています。

(記事かいているときにタイポしているの気が付いたけど、面倒なのでそのままでw)

ソリューションのインポート時の動き

マネージドソリューションとしてエクスポートしたソリューションファイルをインポートしてみます。

結果以下のようになりました。

環境変数を変更できそうですね。

ただ「現在値」をそのままにしていた方は、この段階でエクスポート時の値が見えてしまっています。

したがって、Publicに公開する際などは公開しては困るような値は現在値から消してからエクスポートするようにしたほうがよさそうです。

続いて環境変数の値をセット、変更してみます。

「現在値」が設定されていた方は「リセット」ボタンが表示されていますね。  

これを選択すると、元の値に戻ります。(「現在値」が設定されていたほうだけ)

一応インポートされたソリューションもみておきます。

ちゃんと変更されていますね!

パイプライン

パイプラインでデプロイをしてみます。

こちらもソリューションインポート時と同様に環境変数の変更ができるようになっていますね。

ただし、「現在値」がそのまま設定されていた環境変数に関しては、値が見えています。

パイプラインは異なるテナントへは対象はできず、同じテナント内の異なる環境を対象にしないといけないので、公開しちゃいけない値を不特定多数に公開しちゃった~なんてインシデントは起こらないとは思いますが、まぁ運用としては変更が必要な値は消しておいて、任意もしくそのままの値を利用する場合は現在値を設定したままにしておく。
というのがいいんじゃないでしょうか?(デプロイ時のミス減るかな?)

パイプラインについては、冒頭で紹介した私のJPPC2023の資料みてみてね。

こちらも同様に「リセット」がありますね。

デプロイされたソリューションはこんな感じ。

パイプラインでのデプロイだと「現在値」がそのままだった場合でも「現在値」見えなくなるんだ?

インポート時と動作に差異があるのが若干気になりますね?
別に困りはしないけど。

おわりに

2023年最後の記事でした!(ギリギリ!)

2024年も引き続き皆様よろしくお願いいたしますー

良いお年をーーーーーー

(2023/12/26時点)SharePointリストの画像列と添付ファイルが紐づかないようにする

はじめに

こちらの記事でも紹介しましたが、最近のアップデートでSharePointリストの画像列に画像を追加したときの内部挙動が変更になりました。

koruneko.hatenablog.com

これまではリストの画像列に画像を追加した場合、画像ファイルは"SiteAssets"(サイトのリソースファイル)配下に作成されていました。
しかし最近のアップデートにより、リストの画像列に追加した画像ファイルは同じレコードの添付ファイル列に紐づくようになりました。

このアップデート自体はリストの運用という面で考えると良いアップデートだと思っています。

しかし、Power AppsをはじめとしたPower Platformとの連携を考えると現状(2023/12/26)手放しで喜べるアップデートとはいえません。

上記記事でも記載していますが、まだPower Apps側がこの更新に対応できていなかったりするからですね。

そこでこの記事では、リストの画像列に画像を追加した場合に添付ファイル列に画像ファイルが紐づくのではなく、"SiteAssets"に紐づくようにするやり方を紹介します。

SharePointリストの画像列と添付ファイルが紐づかないようにする

リストの設定を変更する

やり方はいたって簡単です。

リストの設定から添付ファイル列を無効にするだけです。

  1. リストの設定を開きます
  2. 「詳細設定」を開きます
  3. 「リスト アイテムへのファイルの添付」を「無効」にします
  4. 「OK」を選択して変更を適用します

これでこのリストでは添付ファイルは使えなくなります

添付ファイルが利用できなくなることによって(?)画像ファイルは"SiteAssets"配下に作成されるようになります。

実際に動きを見てみましょう。

まず添付ファイルを無効にしているわけですから、当然「ビューの列の編集」には「添付ファイル」列は見当たりません。

試しに以下のような画像を追加してみます。

画像ファイルを開いてみると以下のようにdrives配下にファイルがあることがわかります。
添付ファイルの配下ではないですね。

比較用に画像列の画像ファイルが添付ファイル列に紐づいていた場合のURLも載せておきます。

"SiteAssets"の配下も確認してみましょう。
その前にリストのIDを確認しておきます。

"a2ca97a5-6e7c-49fa-9fda-4b36441b05de"ですね。

"SiteAssets"(サイトのリソースファイル)を確認してみると、上記リストのフォルダが作成されており、もちろん画像ファイルも作成されていることが確認できます。

以上により、SharePointリストの画像列と添付ファイルが紐づかないようになり、前の仕様である"SiteAssets"配下に画像ファイルが作成されるようになりました。
しかし当然ではありますが、このやり方をしてしまうと添付ファイル列を無効にしているため添付ファイルはこのリストでは利用できなくなります

余談ではありますが、もちろんこのやり方にした場合、リスト側の設定がそもそも変わっているので例えばPower Appsから画像ファイルを更新した場合でも"SiteAssets"配下に画像は作成されます。

おわりに

細かい検証まではできていないので、ご利用は自己責任でお願いします。(今後のアップデートで変な挙動になったりしても責任は取れません。)

(2023/12/23時点)仕様が変わったSharePointリストの画像列をPower Appsで利用してみる

はじめに

この記事は、Power Apps Advent Calendar 2023 12/18 担当分の記事です。

SharePointリストの画像列に画像を追加したときの挙動ですが、(私が確認した限りでは)11/11時点では変更されていました。

恐らくこちらのアップデートに関連した更新なのですが、公式で詳しく説明されているドキュメントは私は見つけられなかったです。
(なんかこれだけ書くと、いかがでしたでしょうか?の情報のない記事みたいになっちゃいますねw)

www.microsoft.com

もし公式での詳しいアナウンスをご存知の方はコメントなどでご教示いただけますと幸いです。

アップデート後の仕様

さて、肝心のアップデート内容です。

何が変わったか?というとアップロードした画像ファイルの保存先です。

これまでは、SiteAssets(サイトのリソースファイル)のListsフォルダ配下に、リストIDの名前で作成されたフォルダ配下にそれぞれ画像が格納されていました。

しかしこれからは既存のリストも含めてSiteAssets配下には画像ファイルは作成されなくなりました。

*注意*
これまで保存していた画像は変わらずSiteAssets配下にあります。

ではどこに保存されるようになったか?というと、その行の「添付ファイル」フィールドに保存されるようになりました。

このアップデートによりリストのデータはリスト内だけで完結できるようになりました。
一々SiteAssetsを参照して~ということや、誤ってSiteAssets内のファイルやフォルダを消してしまうという事故がこれでなくなりましたね。

Power Appsで新しくなった画像列を利用する

画像列にアイテムを登録する

登録はこれまでと同じようにできます。

データソースから作成された新しい方のアプリを例に見てみましょう。

チェックアイコンを押してSubmitFormを行ってみます。

SubmitForm(Form1)

無事登録されましたね。

そして見ていただければわかるかと思いますが、添付ファイルフィールドにはなにも登録していなかったのに、添付ファイルにアイテムがあることがわかりますね。

比較用に添付ファイルなしの場合の行も置いておきます。

ただしこちらの画像列に紐づいた添付ファイルですが、リスト上で編集することはできません。

画像列のアイテムを表示する

画像列のアイテムもこれまでと同じように参照して表示が可能です。

もちろん画像のサイズを指定することもこれまで同様可能です。

気を付けないといけないのは添付ファイル項目です。

リスト上では表示されないようになっていましたが、Power Appsから参照すると普通に表示できます。
またこちらPower Appsから編集もでき、削除もできちゃいます。

削除しちゃうと、画像列は添付ファイルのアイテムを参照しているだけなので画像は表示されなくなります。
ただし、画像列には画像の情報はある...というおかしなデータになっちゃいます。

Note
添付ファイルの画像ファイルを消してもリストではしばらく画像は表示できるかと思います。(多分キャッシュかな?)
ただし画像ファイルを選択して、画像の保存されているリンクを開くと対象のファイルが見つからない旨のエラーが返ってくるかと思います。

Power Appsで見るとこんな感じ。

したがって、ユーザの操作ミスや知識不足による誤操作を避けるためにもアプリで添付ファイル列を表示/編集できるようにする場合は、画像列に紐づいたファイルを表示しないようにする必要があります。

さて、フィルタの方法ですが"Reserved_ImageAttachment"で始まらない添付ファイルのアイテム名でフィルタするしか現状対策はないです。

Power AppsからSharePoint Listに接続して得られる情報、ThisItem.添付ファイルではそれが添付ファイルに紐づいたアイテムなのかを確実に判断する術はありません。

画像列の画像ファイル名から判断する。という手もありますがこれには2つ問題があります。

  1. 画像ファイルのファイル名を取得するのがちょっと面倒
  2. Power Appsから画像ファイルを更新した場合、添付ファイルに前のアイテムが残ったままになる

まず1つ目のファイル名の取得ですがファイル名そのままの形式では取得できません。

このような形式から頑張ってファイル名を取得してあげる必要があります。

詳しいやり方は今回の本筋から離れるので割愛。

続いて2つ目の添付ファイルが残ったままの件ですが、リストから画像ファイルを変更した場合は元々設定されていた画像ファイルも添付ファイルから置き換わってくれます。
ただし、Power Appsから変更した場合は添付ファイル列に元々あった画像ファイルは変更されずに、新規画像ファイルが添付ファイルに登録されます。

画像列の画像の向き先は追加された添付ファイルの画像を向いてくれるので、見た目的には問題ないんですけどね。

さて、そんなわけでPower Appsから画像を5回変更した場合添付ファイル列には、
 新規登録時の画像ファイル1枚 + 画像を変更した回数分の画像ファイル5枚
の計6枚の画像ファイルが添付ファイル列に登録されることになります。

IP Manager呼び出して更新してるっぽいですけど何とかしてくれないですかね。。。

上記の理由より"Reserved_ImageAttachment"で始まらない添付ファイルのアイテム名でフィルタして添付ファイルは表示してあげる必要が現状はあります。

Filter(ThisItem.添付ファイル, !StartsWith(DisplayName, "Reserved_ImageAttachment"))

お察しの方もいらっしゃると思いますが、"Reserved_ImageAttachment"で始まるファイルがもしユーザからアップされた場合はこのやり方はアウトです。

より厳密にするのであれば、もうちょっとフィルタ条件を絞るぐらいですかね。。。

どこかで妥協する必要はあります。
100点は求めないでください。

画像列のアイテムを削除する

これまでは画像列にBlank()を渡せば画像ファイルを削除することができていました。

しかし、現時点ではそれでは画像の削除はできなくなっています。

画像ファイルの持ち方の仕様が変わっているので呼び出されるAPI Manager側も変更を加えなきゃいけないはずなんですが、それがまだ(?)行われてないからですね。(多分)

deleteFileAsyncが呼び出されてるっぽいですが、ファイル削除じゃないんじゃないかな。。。

暫定対応として一番簡単なのは、削除用の画像を用意してその画像に置き換えることですね。
実際画像ファイルが削除されるわけではないですが、削除されているように見せかけることでユーザに「ここに登録されている画像はないんだな」と認識してもらう運用です。

  1. 削除用画像を用意
    (動き揃えるために空白の画像でもいいです。今回は説明用に×アイコンの画像を利用。)
  2. 画像の削除を行うためのアイコンやボタンを追加
    (画像の追加コントロールには画像の削除を行う機能はないので独自で実現する必要があります。
    これは今回の仕様変更に関係ありません。)
  3. 画像削除用アイコンやボタンが選択されたときは画像削除用フラグをオンにする

DeleteIcon.OnSelect

UpdateContext({isDeleteImage: true})
  1. 画像削除用フラグが立っていた場合は画像を削除用画像に切り替える

Image.Image

If(
    isDeleteImage,
    Delete,
    // else
    IsBlank(AddPicture1.Media), 
    Parent.Default,
    AddPicture1.Media
)
  1. 画像変更時は画像削除用フラグをオフにする

AddPicture.OnChange

UpdateContext({isDeleteImage: false})

添付ファイルコントロール列をユーザが直接コントロールを弄ることなく既存の添付ファイル列のファイルを消す。
なんてことは現状API直接叩かないとできないはずですので、Pathc()やSubmitForm()では実現できないはずですね。

なにかいい案あれば教えてくださいー

おまけ

他できるようになったこと

Hirano AIさんもおっしゃっていますが、リストに対してドラッグ&ドロップで画像列にファイルを追加できるようになりました!

ただしこれは、SharePoint Listではできません。

Microsoft Listでのみできます。

SiteAssetsに画像が作成されるようにする

---2023/12/27 追記---

以下記事でリストの画像列に追加した画像が添付ファイル列ではなく"SiteAssets"配下に作成される方法を追記しました。
もちろんデメリットもあります。

koruneko.hatenablog.com

おわりに

SharePoint Listの仕様がそもそも変わったことや、それによる変更点などがまとめられたような記事が公式にもないっぽかったので今回まとめました。

Power AuotmateやPower BIでにこれ関連の変更は気が向いたらまとめます。

こうした方が良いよー。や、ここ違うくない?などあればご指摘お待ちしております。

Power Appsのデータ型と計算順序について

はじめに

この記事は、Power Apps Advent Calendar 2023 12/17 担当分の記事です。

きっかけはこちらのツイート

https://twitter.com/koruneko32767/status/1727991967622246608?t=YLkrcNzrC4en37TnhWqhGA&s=19

今回はPower Appsのデータ型と計算順序について記載します。

データ型について

Power AppsではC#Javaのような静的型付けではなく、PythonJavaScriptのような動的型付けとなっています。

変数に入る値からコンパイラ側が、データ型を判断して動的に割り振ってくれるような動きですね。

詳しくはこちらをご参照ください。

learn.microsoft.com

Power Appsでの計算

さて、以上のPower Appsでのデータ型の取り扱いを理解したうえでPower Appsでの計算をみていきましょう。

なお、文字列型とはいっても数値を文字列にして計算を行います。

演算子による型変換

数値型 + 文字列型

まずはツイートでもしていた"数値型 + 文字列型"です。

結果は以下のようになります。

"数値型 + 文字列型"は数値型として計算されるようです。

文字列型 + 文字列型

続いて"文字列型 + 文字列型"です。

"文字列型 + 文字列型"も数値になるようですね。

数値型 & 数値型

続いて"数値型 & 数値型"です。

"数値型 & 数値型"は文字列型になるようですね。

数値型 & 文字列型

続いて"数値型 & 文字列型"です。

"数値型 & 文字列型"は文字列型になるようですね。

どういうことか?

まず、なぜ文字列の算術演算が成り立つのか?からお話すると、冒頭でも触れたとおりPower Appsは数式などに渡すべき型をもとに動的に型をキャストしてくれます。
恐らく市民開発者がデータ型というものをあまり意識せずともある程度のアプリを作れるように。との設計思想ですかね?

したがって、

1 + "2"

みたいな数式は

1 + Value("2")

みたいなことが内部では行われています。

よって当たり前ではありますが、このような計算を行うと以下のようなエラーがでてくることになります。

このエラーは以下のような式を設定した場合と同じエラーですね。

次に返されるデータ型に関してですが、Power Appsで計算を行った場合はその演算子の評価結果によって期待されるデータ型にキャストされます

"+", "-", "*"などの算術演算子では、計算結果として数値型が返ってくるはずですよね。
なので最終結果として数値型が返ってきます。

"&"のような文字列連結演算子を利用した場合は、文字列型が返ってくるはずです。
よって最終結果として文字列型が返ってきます。

learn.microsoft.com

演算優先順位

それでは次に気になるのが演算の優先順位ですね。

"+"と"&"

まずは"+"と"&"どちらが先に計算されるか?についての検証です。



①は以下のような順序で計算が行われているようです。

  1. 2 & 3 + 4
  2. 2 & 7
  3. 27

②は以下のような順序で計算が行われているようです。

  1. 2 + 3 & 4
  2. 5 & 4
  3. 54

どうやら優先順位は算術演算子 > 文字列連結演算子なようですね。

また、文字列演算子が最後に評価されるためデータ型は文字列型になります。

"( )"があった場合

"( )"があった場合は、通常の四則演算と同様に"( )"の中身が先に評価されます。

関数と算術演算子の計算順序

Power Appsで計算を行う場合、算術演算だけでなく関数で計算を行ったりもしますよね。

そのような場合の計算順序に関してです。

この場合は関数の式が先に評価されます。

まぁそういう風に動いてもらわないと困るよね。というのもありますが、関数は"( )"で囲われた場合と同様の計算順序で評価されます。

おわりに

普段何気なくPower Appsで計算を行っているかもしれませんが、数値と文字の混在ケースでの計算が考えられる場合や、計算によって得られるデータ型を意識しなくてはならない場合がPower Appsでアプリを作成している際に出てくるかもしれません。
そのような場合はPower Appsのようなノーコード/ローコードサービスを扱う場合でもデータ型について少し意識してみるようにしてみてください。

また、計算順序をちゃんと意識しないで式を組み立ててしまうと想定通りの結果が得られません。
この計算はどういう順番で行われるのだろう?ということを少し意識して式を作成するようにしてみましょう!

Japan Power Platform Conference 2023 - メインイベント にてPower PlatformのALMについてお話させていただきました

はじめに

この記事は、Power Apps Advent Calendar 2023 12/10 担当分の記事です。

Japan Power Platform Conference 2023 - メインイベントにて登壇させていただきました!

powerplatformconf.connpass.com

私は12/8(金)のデータ・分析&その他で、13:25-14:25から行われたB10&B11のセッションを担当させていただきました。

唯一のパートが分かれたセッションでしたw

お話した内容は「Power Platformで始めるALM構築」という、Power PlatformでALMを行うにはどうすればいいのか?を主題にお話させていただきました。

あまり調べても情報が出てこないような内容なので、結構張り切って記事を書いたのですが。。。
そのせいで145ページにもわたる超大作になってしまい、割と端折ってお話したのですが、それでも時間内にすべておはなしすることができませんしたが。。。

セッションの最後でもお話した通り、このお話はまたどこか別の機会をとって再度お話させていただく予定です。
まだ開催日時などは決まっていないですが、決まり次第告知など行う予定ですので少々お待ちください。

今回こちらの記事ではちゃんとお話することができなかったので、資料の概要を簡単に紹介しようかと思います。

Power Platformで始めるALM構築

資料はこちら

www.docswell.com

ALMとは

こちらのページではALMの概念についてお話しています。
ALMとは、こちらのページの下にもある図の通り、

  1. 計画して
  2. 開発して
  3. テストして
  4. リリースして
  5. 運用して
  6. 課題分析して

を繰り返していくサイクルの事です。
恐らく、ALMという単語を知らなくとも皆さんアプリケーション開発を行う過程で自然とこれらを行っているかと思います。

www.docswell.com

以下のページではPower PlatformでALMを実現するとどういう動きになり、なにができるようになるのかを説明しています。

Power Platformでビルド、テスト、デプロイなどのパイプラインを自動化及び管理することで、開発速度の向上やアプリの信頼性、ユーザエクスペリエンスの向上を期待することができます。

www.docswell.com

こちらではPower PlatformでALMを行う場合に最低限必要な条件をまとめています。

ざっくり、

  • Dataverse環境が必要
  • ソリューションが必要
  • 最低限、開発環境と運用環境は分ける必要がある

ということを理解していただければ。

www.docswell.com

ソリューションとは

これらのページではALMを実現するうえで必須となるソリューションの概要について記載しています。

ざっくり、

  • ソリューションはアプリとかを1つにまとめたパッケージ
  • ソリューションにはアンマネージドソリューションマネージドソリューションがある
    • アンマネージドソリューションが開発環境用
    • マネージドソリューションが運用環境用

ということを理解していただければ。

www.docswell.com www.docswell.com

Power Platformで利用可能なALMの実現方法

Power PlatformでALMを実現するとすると以下4つが候補にあがります。

PowerShellでも実現できますが、実行環境が基本ローカルになる(Azure Functionsに設定するなどすればいいですが、そこまでするならDevOpsやGitHub Actionsでいいんじゃないかな)ということもあり、あまりPowerShellでALMを実現するのは個人的にはお勧めできません。

市民開発者向けの実現方法はPower PlatformのPipelines
プロ開発者向けの実現方法はAzure DevOpsもしくはGitHub Actions
です。

www.docswell.com

PowerShellの利用

PowerShellを利用してのALMの実現について記載していますが、先述の通り個人的にあまりお勧めできないので非常に簡素に記載しています。

www.docswell.com

Pipelinesの利用

Power PlatformのPipelinesを利用してのALMを実現する際のメリットと概要を記載しています。

Power PlatformのPipelinesは直感的な操作でALMを実現することができるように作成されていますので、市民開発者の方も少ない労力と知識でALMを実現することができます。

ただし、Power PlatformのPipelinesを利用する場合はマネージド環境が必要になってくるのでご注意ください。

www.docswell.com

マネージド環境とはなにか?に関してはたなさんのこちらの資料をご確認ください。
こちもJPPC2023でお話された内容ですね!

www.docswell.com

P.19からP.33まではPower PlatformのPipelinesの構築手順および実行手順について記載しています。

実際に試してみたい方はこちらを参考に構築していただければと思います。
また、現在米国環境であればデプロイ時にデプロイされるソリューションの概要のメモをCopilotが作成してくれる機能を試すことができますので、是非試される方は米国環境で試してみてください。

www.docswell.com

最後にこちらではPower PlatformのPipelinesを利用する場合の注意点をまとめています。
こちらの機能はまだPreviewですので「(現時点では)」との記載がいくつかありますが、まだできない(将来的にはできるかも?)という機能がいくつかあります。

www.docswell.com

DevOpsの利用

Azure DevOpsを利用してのALMを実現する際のメリットと概要を記載しています。

Azure DevOpsのビルドタスク(Pipelines)を利用してALMを実現することで、柔軟で複雑なALMを構築することが可能な他、異なる環境へのデプロイや、データの移行(マスタデータの移行とかに使えるかな?)ができるようになります。

ただし、こちらのやり方はプロ開発者向けのやり方なのでご注意ください。

www.docswell.com

P.37からP.68まではAzure DevOpsの構築手順および実行手順について記載しています。

実際に試してみたい方はこちらを参考に構築していただければと思います。

内容みていただければわかるかと思いますが、

  • Microsoft Entra側の設定
  • Azure DevOps側の設定
  • Pipelinesの作成

が必要になってくるので難易度は高めです。

www.docswell.com

最後にこちらではAzure DevOpsを利用する場合の注意点をまとめています。

私も検証しているときに何度やっても上手くいかなかったことなのですが、PowerPlatformImportSolution@2タスクでソリューションインポート時にConvertToManagedオプションを利用してアンマネージドソリューションをマネージドソリューションに変換してインポートすることが恐らくできるはずだと、ドキュメントを見る限り私は理解しているのですが、これが現在うまいこと動いてくれません。。。

よって、動いてないと思われる旨を現在以下issuesで記載しています。(まだ返信なし)

github.com

www.docswell.com

GitHub Actionsの利用

GitHub Actionsを利用してのALMを実現する際のメリットと概要を記載しています。

GitHub Actionsのワークフローを利用してALMを実現することで、柔軟で複雑なALMを構築することが可能な他、異なる環境へのデプロイや、データの移行(マスタデータの移行とかに使えるかな?)ができるようになります。
Azure DevOpsとメリットはそう変わらないです。

ただし、こちらのやり方はプロ開発者向けのやり方なのでご注意ください。

www.docswell.com

P.72からP.90まではGitHub Actionsの構築手順および実行手順について記載しています。

実際に試してみたい方はこちらを参考に構築していただければと思います。

内容みていただければわかるかと思いますが、

  • Microsoft Entra側の設定
  • Power Platoform管理センター側の設定
  • GitHub側の設定
  • GitHub Actionsワークフローの作成

が必要になってくるので難易度は高めです。

www.docswell.com

最後にこちらではGitHub Actionsを利用する場合の注意点をまとめています。

Azure DevOpsのPipelinesで利用可能なヘルパータスクと比較すると利用可能なヘルパータスクは少なめですね。

www.docswell.com

ALMの比較

  • Power PlatformのPipelines
  • Azure DevOps
  • GitHub Actions

の簡易比較として、それぞれの特徴とどういうチームにおすすめなのか?を記載しています。

Power PlatformのPipelinesは手軽にALMを試してみたい方におすすめです。
Azure DevOpsはタスク定義を作成/管理できるメンバーが存在し、ニーズに合わせてパイプラインのカスタマイズを行いたい場合におすすめです。
GitHub Actionsはワークフローを作成/管理できるメンバーが存在し、ニーズに合わせてパイプラインのカスタマイズを行いたい場合におすすめです。

www.docswell.com

ALM Accelerator

Power PlatformでALMの実現を本格的に検討されている場合はこちらの導入を私はおすすめします。

ALM Acceleratorとは、これまで紹介したPower PlatformでのALM管理を補完するために提供されているツールです。

これ単体でALMを実現するわけではなく、あくまでも補完するためのツールな点にご注意ください。

ALM Acceleratorを導入することで、市民開発者とプロ開発者の溝を埋めることができます。
市民開発者にとっては、シンプルな操作でALMを実施することができ、プロ開発者にとってはALMをニーズに合わせてカスタマイズするような高度な機能が提供されています。

www.docswell.com

P.96からP.137まではALM Acceleratorの構築手順および実行手順について記載しています。

実際に試してみたい方はこちらを参考に構築していただければと思います。

内容みていただければわかるかと思いますが、

  • Microsoft Entra側の設定
  • Power Platoform管理センター側の設定
  • ALM Acceleratorの設定
  • 補完するワークフロー側の設定
  • 補完するワークフローの作成

が必要になってくるので構築難易度は高めです。
管理者および開発者にはそこそこの技術力や環境への理解が求められます。

www.docswell.com

最後にこちらではALM Acceleratorを利用する場合の注意点をまとめています。

www.docswell.com

Power PlatformでのALM選択早見表

Power PlatformでのALMを実現する際に、どのサービスを利用すればいいか?を考える際の比較表を紹介しています。

こちらのサイトをまとめたやつです。

learn.microsoft.com

www.docswell.com

まとめ

この資料のまとめです。

Power Platformでアプリを作成したら最終的にALMの構築を目指さないといけないわけではないので、その点はご注意ください。

作成したアプリが自身のビジネスにおいて重要度が高かったり、アプリの機能として複雑性が増してきた場合にALMの導入を検討することになります。

www.docswell.com

おわりに

Power PlatformのALMに関する情報が少なすぎたので、多くの人にALMとはなにか?なにができるのか?Power Platfromではどうやって実現すればいいのか?について詰め込んで紹介しましたが、時間が足りずちゃんと紹介できないのは本末転倒ですね。。。

私のセッションを聞いてくださった方や運営の方々には本当に申し訳なかったと思っています。

こちらの記事や資料、当日のセッションを聞いて疑問点や質問がある方は遠慮なく質問していただければと思います。
私に答えられる範囲で答えさせていただきます。

Power AppsのCopilot controlを利用して、アプリ内で対話形式でデータの概要を質問してみる

はじめに

Power AppsにCopilot controlなるものが追加されていたので、こちらを利用してみました。

learn.microsoft.com

このコントロールを利用することで、アプリ内でユーザがデータについて対話形式で質問することでその内容について回答してくれるようになります。

この記事では、利用までの備忘録(2023/11/06時点)と利用できそうなことを簡単にまとめています。

参考文献

Copilot コントロールをキャンバス アプリに追加する - Power Apps | Microsoft Learn

AI コパイロットの概要 - Power Apps | Microsoft Learn

テーブルを構成して Copilot を使用する - Power Apps | Microsoft Learn

前提条件

環境

現時点では機能を利用するには、環境が米国である必要があります。

learn.microsoft.com

この機能を試したい方で、米国の環境をお持ちでない方はまず米国リージョンの環境を作成してください。

また環境を作成する際は、Dataverseを利用可能な環境を作成してください。

環境設定

米国環境にしたうえで、その環境の設定を変更する必要があります。(デフォルトでオンになっているかもですが)

こちらの公式ドキュメントを参考に設定を行います。

AI コパイロットの概要 - Power Apps | Microsoft Learn

  1. Power Platform 管理センターにアクセスします
  2. 環境 > [米国環境の選択] > 設定 > 製品 > 機能 にアクセスします
  3. "AI Builder のプレビュー モデル"をオンにします
    日本語

    英語

言語設定

Power Appsの設定で言語を"English"にする必要があります。
日本語

英語


この設定だけで会話からアプリを作成する機能が使えるようになりますが、

learn.microsoft.com

Copilot controlを利用できるようにするにはこれだけの設定ではできません。

Copilot controlを利用できるようにするにはブラウザの言語も"English"に設定する必要があります。

Dateverse側の設定

Dataverseをデータソースとして、Copilot controlを利用するにはこちらのドキュメントの設定を行う必要があります。

learn.microsoft.com

インデックス作成を有効にする(Enable indexing)

DataverseでCopilotを利用可能な状態にするんは、"Track changes"(変更の追跡)と"Apperar in search results"(検索結果に表示)がオプションよりオンになっている必要があります。

既定のテーブルではこの設定はオンになっているかと思いますが、カスタムテーブルではこの設定はデフォルトではオンになっていないので、自身でオンにする必要があります。

  1. 対象のテーブルを開き、"Properties"を開きます
  2. "Advances options"より、詳細オプションを設定します
  3. "For this table"内の"Track changes"と、"Row in this table"内の"Apperar in search results"をオンに設定して保存します

列を構成する(Configure columns)

検索対象の列と、ユーザに返答する列の情報を構成する必要があります。

この設定は以下から行うことできます。

  1. "Data experiences"より"Views"を選択します
  2. "Quick Find Active [テーブル名]"というビューを選択します
  3. 2で選択した列を編集します
  4. 画面右下にある"Find by ..."より、"Edit find table columns ..."を選択してユーザとの対話により検索対象としたい列を追加します
    不要な列については"×"より削除してください
  5. 画面中央にある"View columns"を選択して、ユーザとの対話により応答によって返してもらいたい列を追加します
    不要な列については"×"より削除してください


    ドキュメントでは以下のように記載されています。
    これを意識して設定するとよいかもです。

    ユーザーがすべての列を返す自由回答式の質問をしたときに、Copilot エクスペリエンスでエンド ユーザーに返される列を定義する必要があります。
    これを行うには、ビューに列を追加します。 Copilot の回答に含めることができるデータは限られているため、正確な回答を得るには質問の質が高いことを確認することが重要です。

  6. 最後に"Save and publish"より変更を保存して公開します

Copilot controlをアプリに追加する

アプリの設定

Copilot controlを利用するには、"Copilot component"がオンになっている必要があります。

Settings Upcoming features > Preview より、"Copilot component"をオンに設定してください。

多分前提条件の設定をクリアしている場合は、この設定が表示されてデフォルトでオンになっているかと思います。

逆にここの設定が出てこない方は前提条件の設定に漏れがあると思いますので再度確認してみてください。

アプリに追加する

Copilot controlは、Popular > Copilot (preview) もしくは Input > Copilot (preview) にあります。

アプリ内に追加したら、"Data source(Items)"もしくは Items より、Dateverse側の設定を行ったDataverseテーブルを設定します。

これでCopilot controlを利用できます!

"Fields"でテーブルのフィールドを設定可能ですが、ここは設定していても設定していなくても変わらないような...?

というより、ドキュメントで各プロパティの説明が以下のように記載されていますが、これ現時点では機能していないような気がする。。。

learn.microsoft.com

要検証ですかねー

実際に動作を試してみる

自然言語でチャットすることでデータソースの情報を返してくれます。

例えば、データソースの件数を「How many data items are in this data source?」という質問できいてみたところ、ちゃんと5件だよ。と返してくれました。

また、日本語での質問にも返答してくれます。
ただし、言語英語にしているからか返答は英語ですね。

ただしこんな感じで「日本語で教えて」というとちゃんと日本語でも答えてくれます。
ここはさすが裏ではAzure OpenAI Serviceが機能しているだけありますね。

また、こんな感じの曖昧な質問にも答えてくれます。

ただここまで曖昧だと正しく返してくれないようです。
ここはChatGPTを上手く利用するためのプロンプトに似ていますね。

ただ、こんな感じでフィールドの列名や入っている情報からそのフィールドがどのようなデータのフィールドなのか推測して、応答を返してくれるのは凄いですね。

ちなみにこのテーブルは会話から生成したテーブルなので列の説明なんてものは設定されていません。

これを活用すれば、データ一覧画面で様々な情報でフィルタできるように設定しなくともよくなるかもしれないですね。

あとは、テーブルコントロールみたいな形式でいいからテーブル形式でデータを出力してくれると嬉しいですね。

[おまけ]SharePoint Listをデータソースに設定した場合

SharePoint Listをデータソースに設定することも可能です。

ただ上手く検索できないですね。。。

ただ、これが返ってくるのはインデックス作成がサポートされていないImage列が含まれているからの可能性があります。

support.microsoft.com

以下のようにインデックス作成がサポートされている列のみで構成されている列ですと、結果は返ってきました。

ただし、うまく動いてくれてないように見えますね。。。

今後SharePoint List(Microsoft List)でも動くようになるといいなー。。。
と思いましたが、うーーん難しそう。

おわりに

ギークフジワラさん@geekfujiwaraにDataverse側の設定も必要なことを教えていただくまで、まだこの機能は使えないと思っていました。

改めて教えていただきありがとうございました!

まだまだプレビューの機能なので制限なども多いですが、簡単にデータソースの情報を対話形式で質問できるようになるのは素晴らしいですね!

今後のアップデートに期待しましょう!


スポンサードリンク