GitHub Spark で入力した IP が Azure のサービスで使用されているものかを確認するアプリを作成してみた際の知見を。
作成したアプリについては、投稿時点では https://azure-ip-resolver–masayukiozawa.github.app/ で公開しています。
Contents
作成したアプリ
今回作成したアプリですが、IP アドレスの一覧を指定して、その IP が Azure で使用されているかを確認するアプリとなります。
次のような UI となっており、指定した IP アドレスを Azure で使用されている IP アドレスなのかを解析し表示するものとなります。
機能としては https://www.azurespeed.com/Azure/IPLookup と類似のものとなりますが、このような機能を GitHub Spark を使用して自然言語で作成したのが今回のアプリとなります。
Azure の IP アドレスの解析に使用するファイルの利用方法
Azure で使用されている IP アドレスを解析する際には Azure IP Ranges and Service Tags ? Public Cloud で提供されている JSON を使用するか、Service Tags REST API を使用する方法があるかと思います。
利用者が Azure のサブスクリプションを保有していない可能性があるのと、現在公開されている情報では、REST API にアクセスするための資格情報を GitHub Spark でセキュアに取り扱わせるのが難しそうなので、今回は、JSON で対応をしたいと考えています。
GitHub Spark にはアセットをアップロードすることができますが、アップロード可能なファイルは「png / jpg / gif / svg / webp / pdf / mp3 / ogg / mp4 / webm」に制限されています。
GitHub Spark はレポジトリに連携することで、手動でファイルアップロードをすることができ、アセットのディレクトリに JSON を格納させることで、プレビュー画面ではアップロードした JSON を使用することができたのですが、Publish したサイトに JSON は含まれていないようで、Publish 後のアプリに JSON を使わせること出来ませんでした。
今回のツールは自分がメンテナンスできれば良いので、ひとまず、Azure IP Ranges and Service Tags ? Public Cloud の JSON を直接使用することにしました。
この JSON は更新が入るたびにファイル名が変わりますが、とりあえずは現時点の内容で確認ができればよいので、現状のファイル名で固定で使用しています。
フロントのコードから MS のサイトの JSON を読み込むため、CORS の影響を受けますが、ひとまず corsproxy.io で回避しています。
(時間の余裕ができたらファイルは Azure BLOB に保存したものを使用させるように処理を変更しようかと)
GitHub Spark に KVS に JSON の全内容を保存しておくということも考えたのですが、KVS に JSON を貼り付けようとすると応答が返って来なくなったため、これを実現することはできていません。
処理の中で AI を活用する
チュートリアルの Step 5: Refine AI capabilities で記載されていますが、GitHub Spark の AI は GitHub Models で駆動しているようですので、GitHub Models のモデル を使用できるのかと。
(現状は、ai21-jamba-instruct / cohere-command-r, r-plus / gpt-4o, 4o-mini / metta-llama 3.1 / mistral-large, nemo , small / phi-3-medium, mini, small 辺りが使用できるようです)
Next, let’s iterate on the AI capabilities included in our app, which are powered by GitHub Models.
今回のようなアプリケーションで AI をどのような箇所に使用できるかを考えてみたのですが、次のような処理を AI で実施させると効率がよさそうでした。
- 指定された IP からローカル IP アドレスを除外
- 指定された IP で重複しているものを除外
- IP アドレス順で並び替える
プロンプトでこれらの処理の実装を指示して実装させることもできますが、プロンプトで単純に処理を生成させるとクライアントサイドの処理とし実装されることがあります。
このようなルールが明確になっているような処理については、AI に任せてしまったほうが実装がシンプルになるのではないでしょうか。
「xxx の処理については、AI で処理をさせ、その応答を使用してください」というようなプロンプトを使用すると、該当の処理は AI を使用するように誘導することができます。(今回のケースであれば spark.llm を使用するように実装されます)
GitHub Spark で AI が使用される場合、呼び出しのプロンプトは「Prompts」に表示されるようになりますので、プロンプトのカスタマイズは Edit 画面から行うことができます。(コードに記載されているプロンプトを直接修正することもできるようです)
GitHub Spark の特徴として AI が利用できるという点がありますので、AI が活用できる処理については積極的に使用するようにしておきたいですね。
コードの修正と破棄
GitHub Spark のコードの修正方法はいくつかの方法があります。
- Iterate からプロンプトで修正を指示
- Code Mode でコードを修正
- Select element to edit でプレビューから要素を選択して修正を指示
- Open codespace で Codespace を使用してコードを修正
- Create repolistory でレポジトリを作成してリポジトリからコードを修正
これらの方法でコードを修正することができます。
手動で修正した場合は「Manual edit」、リポジトリからコードを修正した場合は「Synced from repository」と Iterate に表示され、コードの反映が行われますが、リポジトリから修正した場合の同期には多少のタイムラグがありそうでした。
コードの修正の指示をしていると、想定とは異なった修正 / 破壊的な変更が行われることがあります。そのような場合 Iterate で出した指示をクリックすることでその指示の段階のコードとなるようです。
しかし、
- クリックしても反応がない
- リポジトリで変更した内容が反映されない
- エラーがループ / Loading の状態が続き、ReadOnly の状態が解除されず Iterate をクリックできず、Code Mode も Read Only になって制御ができない
というような状態になることがありました。
このような場合、新しいアプリケーションを作成して、リポジトリから最新または特定のコミットのコードを移植して復旧したほうが良いケースがありました。
Limit に達したことによる編集の制限
GitHub Spark を使用していて、あるタイミングで次のようなメッセージが表示されるようになりました。
You have reached your editing limit for sparks this month. If you would like higher usage limits, contact our team.
投稿時点では GitHub Spark には、月内の編集の制限があるようで、上限に達するとその月内は編集ができなくなるようです。公開しているアプリケーションについては継続して使用することができました。
この管理は Premium Request の消費状況とは別のようで、Premium Request としては余裕がある状態でこのメッセージにより編集が制限されました。
Billing and limits for Spark app deployment に制限がかかることは明記されていますが、今回のような編集ができなくなるという制限については、まだ、記載が無いようですので、制限については今後もウォッチが必要そうですね。
Community の活用
GitHub Spark は Public Preview が始まったばかりで情報はまだ少ないかと思います。
不明なエラーが発生した場合は、Community の活用が不可欠になるかと思います。
- GitHub Spark in public preview for Copilot Pro+ subscribers #163110 のスレッド
- Discussions に「Copilot in GitHub」「Querstion」のラベルをつけて Discussion をオープン
今のところこれらの方法が GitHub Spark の疑問点を解決するために役立つのではないでしょうか。ディスカッションは活発に行われていると思います。