
こんにちは。ACS事業部の越川です。
- やったこと: GitHub Copilot CLI に Fabric 操作を任せて測る
- 計測結果: lab別の消費
- 遅いモデルとの付き合い方
- 一番の難所で起きたこと
- 軽量モデルは、難所でツールを使いこなせなかった
- 見えてきたこと: コストは「使う人」と「使い方」で決まる
- おまけ: スキルは「呼ばれた時だけ」コストになる
- まとめ
- 注記
- ACS 事業部のご紹介
GitHub Copilot が2026年6月から従量課金(AI Credits)へ移行しました。社内でも「実際どれくらいクレジットを使うのか」「使用量をどう可視化するか」が話題になっています。気になるテーマですが数字は測ってみないと分かりません。
そこで Microsoft Fabric のハンズオン教材を題材にしました。GitHub Copilot CLI へ操作を丸ごと任せて、1タスクあたりどれだけAI Creditsを消費するのかを実測した記録です。結論を先に言うと、効いてくるのは時間あたりの消費量でした。
本記事の数値はすべて私自身が手元の環境で実行して計測した一次情報です。ハンズオンの内容は Lakehouse の作成からデータ変換、レポート作成まで。一連のデータ基盤構築です。
やったこと: GitHub Copilot CLI に Fabric 操作を任せて測る
GitHub Copilot CLI には Microsoft Fabric を操作するためのスキル群(プラグイン)が用意されています。自然言語で「Lakehouse を作って」「このデータを変換して」と指示すると、CLI が裏側で Fabric の REST API を呼び出すコマンドを生成して実行します。
今回はこの「自然言語で全部任せる」やり方を使いました。ハンズオンの各ステップ(以下 lab と呼びます)を順に進め、ステップごとの AI Credits(以下 AIC)と所要時間を記録します。あとでこの2つから1分あたりの消費も求めます。モデルは Auto(自動選択)に任せ、どのモデルが選ばれるかも観察しました。
計測結果: lab別の消費
実測値は次の通りです。ここで指標を3つに分けておきます。区間AICはその lab で使った消費量。所要時間はかかった時間。1分あたりAICは区間AICを所要時間で割った時間あたりの消費量です。モデルは Auto により GPT 系のコーディングモデルが選ばれました。
| lab | 内容 | 累計AIC | 区間AIC | 所要時間 | 1分あたりAIC |
|---|---|---|---|---|---|
| 02 | Lakehouse 作成・データ取り込み・変換 | 86.8 | 約87 | 約32分 | 約2.7 |
| 03 | ショートカット連携 | 152 | 約65 | 約25分 | 約2.6 |
| 04 | ウェアハウスのディメンション設計 | 228 | 約76 | 約13分 | 約5.8 |
| 05 | セマンティックモデル作成 | 276 | 約48 | 約15分 | 約3.2 |
| 06 | Power BI レポート作成(未完) | 453 | 約177 | 30分以上 | 約5.9 |
所要時間は、GitHub Copilot CLI のセッションログに残る各操作の時刻から求めました。1 AI credit はおおよそ0.01ドル相当です。
ここで一番の気づきがありました。コストを見るうえで効くのは、1分あたりのAIC消費量だったということです。
たとえば lab 04(ウェアハウスのディメンション設計)は所要時間が約13分と一番短い。なのに1分あたりAICは約5.8と最も高い部類です。逆に lab 02(Lakehouse 作成)は約32分と一番長いのに1分あたりは約2.7と低め。時間が長い=重い、ではないわけです。
lab 02 が長かったのは環境構築や初回の手探りで時間が流れたためです。AIが濃く働いていたわけではありません。一方 lab 04 は短時間にAIが集中的に判断と往復を重ねていました。AIががっつり頭を使った区間ほど1分あたりAICが高くなります。後述の lab 06 もこの値が約5.9と最も高いまま、最後まで仕上がりませんでした。
遅いモデルとの付き合い方
Auto が選んだコーディングモデルはトークン単価が安い部類でした。ただし応答ははっきり遅い。ツールの呼び出しを細かく刻み、そのたびに確認を挟んで慎重に一歩ずつ進めるためです。1つの lab で何十回ものツール実行と確認が発生していました。
では遅さは欠点なのか。実務的には工夫の余地があります。AIが処理している間、人間は手が空きます。その時間に別の作業を進めればいい。実際、応答は遅くてもハンズオン全体の所要時間は教材の想定(各 lab 15分から25分程度)に概ね収まりました。
ポイントは、AIが自分で進めてくれる間は人間が並行作業で待ち時間を埋められることです。応答の速さそのものより、待っている間に別タスクへ切り替えられるかどうかが効いてきます。逆にこれが効かなくなる場面が、次の lab 06 で起きました。
一番の難所で起きたこと
ハンズオンで本来のゴールとなる lab 06(Power BI レポート作成)で状況が大きく変わりました。ここで起きた一連の流れを先に図にまとめておきます。

ここで私はあるヒューマンエラーをしていました。レポート生成に必要なプラグインを1つ入れ忘れていたのです。GitHub Copilot はレポート生成のスキルを呼び出そうとして「スキルが見つからない」と検知しました。代替手段をいくつか試した上で、正直に「この環境では実行できない」と止まりました。
暴走せず、できないことをできないと言う。これ自体は誠実な振る舞いです。ただし原因(プラグインの入れ忘れ)を特定して補完するのは人間の出番でした。前提条件のドキュメントを読み返し、不足していたプラグインを導入してセッションを再起動します。
ここで興味深いことが起きました。再起動後、Auto が選ぶモデルがより軽量なモデルに切り替わったのです。
軽量モデルは、難所でツールを使いこなせなかった
プラグインは入れ直したので今度は通るはずでした。ところが軽量モデルは用意されたレポート生成スキルを呼び出しません。自前で Fabric の REST API を直接叩いてレポート定義を組み立てようとして泥沼にはまりました。
レポート定義のスクリプトを十数回書き直し、API のスキーマ要件(非同期処理の扱い・定義ファイルの形式・参照の指定方法など)と延々格闘しています。途中で頼んだはずの Power BI レポートから、より簡単なノートブック作成へ方針がすり替わる場面もありました。
最終的に私はこのレポート作成に「あと10分」という締め切りを設けました。実務には必ず締め切りがあります。無制限に時間をかければいつかは通るかもしれません。ですがそれは実務の評価になりません。
結果は時間切れで未完。再起動後のセッションだけで177 AIC を消費して、それでも lab 06 は仕上がりませんでした。
見えてきたこと: コストは「使う人」と「使い方」で決まる
この実測を通して、いくつかはっきりしたことがあります。要点を先に図にまとめておきます。

1つ目。安いモデルが必ずしも安く済むとは限りません。 単価は安くても、判断が必要な難所でツールをうまく選べず何度も往復してやり直すとトークンは積み上がります。今回の軽量モデルは速く大量に出力できる反面、その速さで失敗を高速に繰り返しました。
2つ目。遅いモデルでも自律して動くなら、人間は並行作業で待ち時間を埋められます。 ただし自律できずに途中で止まったり変な方向に進んだりすると、人間が張り付いて監視せざるを得ません。そうなると人間は他の作業に切り替えられない。1つのタスクに人間の集中が拘束されてしまうのです。
3つ目。これが一番大事だと感じた点です。高性能なモデルが提供している価値の正体は、人間が張り付かなくて済むことです。 素早く自律的に長い手順を一気に通してくれる。人間の注意力と集中の切り替えを肩代わりしてくれます。逆にそれを必要としない軽い作業なら安いモデルで十分です。
コストはモデルの高い安いだけでは決まりません。タスクの性質と、使う人がどこを自分でやりどこをAIに任せるかという取捨選択で決まります。AIに何でも対話で投げる人ほどクレジットを消費する。自力で要所を押さえられる人ほど適切に少なく使えるのです。
おまけ: スキルは「呼ばれた時だけ」コストになる
今回 Fabric 操作に使ったスキル群について、もう一つ確認できたことがあります。
スキルは普段、名前と短い説明(カタログ)だけがAIから見えています。AIが「これが必要だ」と判断して呼び出した瞬間に、初めてその本文(詳細なマニュアル)が読み込まれる仕組みでした。実行ログ上、すべてのスキルが「エージェントが必要時に呼ぶ」形で発火しています。
これがコスト面で効いてきます。インストール済みのスキルをすべて常に読み込んでいたら、本文の合計はかなりの分量(ざっと20万トークン規模)になります。しかし実際に消費したのは呼び出された分だけ(数万トークン規模)でした。スキルを大量に用意しても使った分しか課金されません。必要な知識だけを動的に読み込む、よくできた設計です。

まとめ
GitHub Copilot CLI に Fabric の操作を丸ごと任せてコストを実測してみました。分かったことを一言でまとめます。AIのコストは「どのモデルを使うか」より「誰がどう使うか」で決まる、ということです。
高性能なモデルは無駄な重課金ではありません。人間の集中を解放してくれる投資です。一方で軽いモデルは軽い作業には最適です。ですが判断が必要な難所では往復を量産し、かえって時間も人手もコストもかかります。大事なのはタスクの性質を見て適材適所でモデルを選ぶこと。そしてAIに任せる部分と自分でやる部分を見極める力です。
数字で測ってみると、漠然とした「AIは高い・安い」の議論がぐっと具体的になりました。気になる方はぜひご自身の手元のタスクで測ってみてください。
注記
- 本記事の AI Credits(AIC)・所要時間・モデルの挙動は、すべて筆者が手元の環境で GitHub Copilot CLI を実行して計測した一次情報です。実行内容によって数値は変動します。
- 計測は GitHub Copilot CLI のモデル自動選択(Auto)で実施しました。Auto では選ばれるモデルが変わることがあり、本記事でもセッションをやり直した際にモデルが切り替わりました。
- 1 AI credit はおおよそ0.01ドル相当です。トークン消費量からの概算を含む箇所があり、厳密な値ではなく傾向を示すものとしてお読みください。
- スキル本文のトークン量は、ファイルの文字数からの概算です。比率(呼ばれた分だけ消費されること)を示す目的で記載しています。
- GitHub Copilot のモデルや課金の仕様は変更される可能性があります。利用時点の公式ドキュメントをご確認ください。
ACS 事業部のご紹介
私の所属する ACS 事業部では、開発者ポータル Backstage、Azure AI Service などを活用し、Platform Engineering + AI の推進・内製化を支援しています。
www.ap-com.co.jp www.ap-com.co.jp www.ap-com.co.jp
また、GitHub パートナーとしてお客様に GitHub ソリューションの導入支援を行っています。 GitHub Copilot などのトレーニングなども行っておりますので、ご興味を持っていただけましたらぜひお声がけいただけますと幸いです。
一緒に働いていただける仲間も募集中です! ご興味持っていただけましたらぜひお声がけください。
※求人名の冒頭に【ACSD】と入っている求人が当事業部の求人です