Gemini Canvasから出力・ダウンロードできるファイル形式一覧 Gemini Canvasの強みは、資料やWebページ用のビジュアルを出力し、多様なファイル形式へ変換できる点にあります。

この記事は、BASEテックブログ夏のブログリレー4日目の記事です。 BASE株式会社で PAY IDアプリのiOSアプリエンジニアをしている kakkki です。 最近、コーディングエージェントの進化によって開発のスピードが上がり、プルリクエスト（以下、プルリク）の数も大きく増えました。弊社のiOSアプリチームでも、git worktreeを活用して複数の開発を並行して進める場面が増えています。 開発が速くなるのはうれしい一方で、次のような課題も目立つようになってきました。 開発のたびに必要なシミュレーターや実機での動作確認の手間をどう減らすか 増えていくプルリクのレビュワーやデザイナーのUI確認の負担をどう軽くするか そんな中我々が工夫してる取り組みとして、次の2つのコーディングエージェント向けスキルについて紹介します。 iOSシミュレータを操作し、動作確認とスクリーンショット撮影を行うスキル 撮影したスクリーンショットをアップロードし、プルリクに貼り付けるスキル この2つを組み合わせ、UI変更の動作確認からプルリクへのスクリーンショット添付までを、コーディングエージェントに任せるフローを確立しています。 きっかけ：膨大なUIパターンのデグレチェック きっかけは、弊社のアプリ「PAY ID」の商品詳細画面の機能追加のための開発をしていたときのことでした。 商品詳細画面は、10年以上にわたって作り続けられてきました。機能追加や仕様変更を重ねた結果、機能や商品の状態に応じたUIパターンは膨大な数にのぼり、長年の仕様を支える条件分岐が積み重なっています。そのため、ちょっとした改修でも「他の表示パターンに意図しない影響が出ていないか」というデグレチェックが欠かせず、そのUI確認とレビューに大きなコストがかかっていました。 PAY IDアプリ 商品詳細画面のスクショです 同じ商品詳細画面でも、商品の状態によってバッジやボタンの構成が変わります（画面は開発環境のテストデータです）。 そんな中で思いついたのが、UI確認やスクショといった「証跡を残す作業」そのものを、コーディングエージェントに任せられないかというアイデアでした。 変更箇所に影響しそうなUIパターンをエージェントがひとつずつ洗い出し、シミュレーターで動作確認をして、スクリーンショットを集めてプルリクに貼ってくれる、といったフローです。 これができれば、影響しそうなパターンの洗い出しやそれぞれのパターンのUI変更の確認がとても楽になると考えました。 エージェントに動作確認をさせるのは、意外とあっさりできた 最近はコーディングエージェントがシミュレータを操作して、自律的に動作確認まで行えるようにするツールが活発に開発・公開されています。 私たちのiOSアプリチームでは現在、Software Mansionが開発するArgentを使って、エージェントが動作確認するためのスキルをリポジトリ内に置いています。Argentは、コーディングエージェントがiOSシミュレータを操作・デバッグできるためのツールキットで、タップやスクロールなどの操作をエージェントに提供します。 これにより、変更対象の画面にエージェントが自分で遷移したり、各UIパターンの画面を自律的に探索・修正した箇所までスクロールする、というところは意外と早く実現できました。 シミュレータ操作側のスキル（ios-simulator-controller）の中身は、こんな内容です（抜粋・一部一般化しています）。 --- name : ios-simulator-controller description : | Argentを使って、iOSシミュレータ上のアプリを コーディングエージェントが操作する。 画面遷移、UI操作、状態確認、スクリーンショット撮影までを扱う。 --- 【基本方針】 - 目的の画面には、可能であればdeeplinkを使って直接移動する - 操作前に現在のUI要素を取得し、アクセシビリティIDやラベルから対象を特定する - 固定座標による操作は、ほかの方法で要素を特定できない場合に限定する - 操作後は画面の状態変化を確認してから、次の操作へ進む 【操作できること】 - アプリの起動・再起動 - deeplinkによる画面遷移 - UI要素の取得 - タップ、スクロール、テキスト入力 - UI要素の表示・非表示の待機 - スクリーンショット・画面録画 【ワークフロー】 1. 操作対象のシミュレータを特定する 2. 目的の画面へ移動する 3. 現在のUI要素を取得する 4. アクセシビリティIDやラベルから操作対象を探す 5. タップやスクロールなどの操作を行う 6. 目的の状態へ変化したことを確認する 7. 必要な画面のスクリーンショットを保存する 【操作の定石】 - 画面遷移後は一定時間待つのではなく、目的のUIが表示されるまで待機する - スクロールは「スクロール → UIを確認」を、上限を決めて繰り返す - ダイアログなどが操作を妨げている場合は、先に閉じてから本来の操作へ戻る - 操作が反応しなかった場合は状態を確認し、別の候補や経路を試す 操作のたびに現在のUIを読み取り、画面遷移の完了や操作結果を確認しながら次へ進むことで、エージェントによる動作確認の再現性を高めています。また、運用中に見つかったアプリ固有の操作方法や例外パターンも、少しずつスキルへ蓄積しています。 スクショは撮れた。悩んだのは「置き場所」でした 悩んだのはその先です。 撮ったスクショをどこに置いて、レビュアーやデザイナーなど他のメンバーとどう共有するか。 2026年8月現在、GitHub APIやGitHub CLIには、プルリクのディスクリプションに画像ファイルをアップロードする公式な手段がありません。 人間が手操作で貼り付けることはもちろんできますし、Computer Useのような仕組みでエージェントに直接貼らせることもできなくはないのですが、どちらも人間の手間やトークンコストがかさんでしまい、やりたいことに対して大げさなフローになってしまいます。 そんなときに知ったのが、いわゆる「Companion Branch Approach」という方法でした。画像を置くための専用ブランチを別に用意して、そこに画像をコミットしてプッシュしつつ、プルリクのディスクリプションからはそのブランチ上の画像URLを参照する、というアプローチです。 たとえば、プルリクのディスクリプションに次のようなイメージタグを書くイメージです。 < img src = "https://github.com/sample-org/sample-app/blob/screenshots/pr-1234/item_detail.png?raw=true" width = "300" /> 画像用ブランチ上のファイルを ?raw=true 付きのURLで参照すると、ディスクリプション上でそのまま画像として表示されます。 この方法のいいところは、開発用のブランチに画像を混ぜなくて済むことです。専用ブランチに分けておけば、ソースコードの履歴を汚すことなく、GitHub上のURLで画像を参照できます。 私たちのチームではGitのorphanオプション（ --orphan ）で生成したブランチを利用しています。画像を置くだけのブランチに、ソースコードの履歴は要りません。orphanオプションのブランチなら、まっさらな履歴からスタートできます。 orphan The act of getting on a branch that does not exist yet (i.e., an unborn branch). After such an operation, the commit first created becomes a commit without a parent, starting a new history. — gitglossary - orphan | git-scm.com このorphanオプションのブランチを、私たちは _assets という名前で運用しています。中身は、プルリクの番号ごとにディレクトリを切って画像を置くだけの、とてもシンプルな構造です。 _assets ブランチ ├── README.md ├── pr-1234/ │ ├── item_detail_default.png │ ├── item_detail_soldout.png │ └── item_detail_campaign.png ├── pr-1235/ │ └── cart_badge_count.png └── pr-1250/ ├── search_result_grid.png └── search_result_empty.png _assets ブランチへの画像アップロードとディスクリプションへの画像貼り付けの処理は、以下のようなコーディングエージェントのスキルに落とし込みました。 画像アップロード側のスキル（pr-screenshot-uploader）の中身は、こんな内容です（抜粋・一部簡略化しています）。 --- name : pr-screenshot-uploader description : | スクリーンショットを永続的な _assets orphan branch にアップロードし、 PR description に markdown テーブルとして埋め込む。 フィーチャーブランチを汚さずに画像を GitHub 上で参照可能にする。 --- 【概要】 - ` _assets ` はプロジェクト全体で1つだけの永続 orphan branch。PR ごとにサブディレクトリで管理する - 一時 clone を使って操作するため、元のワーキングツリーには一切触らない - git 操作はすべてシェルスクリプト内で完結し、AI が直接 git コマンドを実行しない - PR description の更新は HTML コメントマーカーで境界を定義し、何度でも再実行できる 【ワークフロー】 1. スクショの保存先ディレクトリを確認する（表示速度のため必要に応じてリサイズ） 2. スクリプトで ` _assets ` ブランチへアップロードし、画像 URL の一覧（JSON）を受け取る 3. 画像 URL から markdown テーブルを組み立てる（カラム構成や行数は AI が柔軟に決める） 4. スクリプトで PR description の「スクリーンショット」セクションを更新する 5. 完了報告（ブランチ / PR / 画像数） スクリプト全文は長くなるため省略しますが、処理は大きく2つに分かれます。 画像を _assets ブランチへアップロードする _assets ブランチだけを一時ディレクトリに clone する pr-<番号> へ画像をコピーして commit ・ push する 参照する画像URLの一覧(JSON)を取得する push が競合した場合は rebase して再試行する プルリクの説明文を更新する 現在の説明文をバックアップする HTMLコメントで囲んだ「スクリーンショット」セクションに対して、取得した画像URLを含んだ内容で追記する 更新結果を取得し、正しく反映されたことを確認する git 操作やプルリクの更新のような「間違えたくない部分」はシェルスクリプトに閉じ込めています。どのようにスクショ画像を並べてテキストによる説明を追記するかはAIの判断に任せています。 今では、開発セッションの中で「プルリクのディスクリプションに、修正した範囲のスクショを貼っておいて」と自然言語で指示するだけで、エージェントが修正箇所のスクショをプルリクのディスクリプションに上げてくれます。 導入して何が変わったか これらのスキルをリポジトリに置いてから、プルリク作成時のスクリーンショット添付が劇的に楽になりました。今ではシミュレーターでのスクショの撮影からプルリクへの貼り付けまで、エージェントが一気通貫でやってくれます。 ただし、ログインが必要な画面など、エージェント単体ではたどり着きにくい画面もあるので、すべての画面で手動操作をゼロにできたわけではありません。 それでも、日々のiOSアプリ開発の大半でこの仕組みを活用できるようになり、いろいろな面で良い効果がありました。 デザイナーとのやりとりが速くなった たとえば何パターンものUIバリエーションがある画面をデザイナーが実機でチェックしようとすると、手動でひとつずつ画面遷移して目視確認していくことになり、とても労力がかかります。 最近は、変更したUIパターンを網羅したスクショ一覧を貼ったプルリクを共有することが多いです。デザイナーは開発アプリを直接操作しなくても、一覧化されたスクショを見るだけで手早くフィードバックできるようになりました。 もちろん今でも最終的には実機確認はしていただくのですが、「エンジニアが開発する → デザイナーがUIをレビューしてフィードバックする → エンジニアが修正する」というフィードバックループが、以前より速く回るようになりました。 データの状態に応じてUIのバリエーション数が多い画面ほど地味に効いてきます。 スクショがすぐに上げ直せるので修正サイクルが早くなった 手動でスクショを貼っていた頃は、実装を修正したら人力で画像を上げ直すのを頑張るか、古いスクショのまま放置されるかのどちらかになりがちでした。 今では、修正後に「もう一回動作確認して、スクショを上げ直しておいて」と1プロンプト投げるだけで、エージェントがすべてのスクショを自動でアップロードし直してくれます。 気軽に修正して上げ直せるので、開発したものをクイックに共有してフィードバックをもらって修正するというループが回しやすくなったと感じています。 スクショのあるプルリクが当たり前になってレビューコストが下がった プルリクの数が増えていく中で、レビューするコストの増大は見逃せません。UIの変更が含まれるプルリクであれば、極力修正箇所のスクショを添付することで少しでもレビュアーのコストを軽減できると考えています。 iOSアプリチーム内ではその共通認識があるのでもともとスクショを手動で上げることにも抵抗がなかったのですが、最近はiOSアプリエンジニア以外の方がiOSアプリのプルリクを上げてくれる機会も増えてきました。 このスキルがあれば気軽にスクショをプルリクに用意できるので、レビューコストの軽減に役立っています。 まとめ この仕組みを導入してから、4ヶ月ほど経ちました。今では「修正した範囲のスクショを貼っておいて」のひとことが、各エンジニアのコーディングエージェントとのやりとりの中に定着しています。 チーム全体として、「開発した変更を周りに伝えるハードル」が下がった と実感しています。 コーディングエージェントの進化で、コードを書くこと自体はどんどん速くなっています。一方で、「その変更が正しいかを確かめること」と「何をしたのかを周りに共有すること」は、まだまだチームごとの工夫が必要な領域だと感じています。 開発したものの確認や共有のやり方に似たような課題を感じている方の参考になれば嬉しいです。小さな仕組みですが、チームのフィードバックループは思った以上に速く回るようになるはずです。 BASEでは、一緒にプロダクトを作ってくれるエンジニアを募集しています。ぜひお気軽に採用情報をご確認ください。 open.talentio.com 明日は、Otsukaさんの記事です。お楽しみに！

「金融リファレンスアーキテクチャ日本版」は、2022 年 10 月に v1.0 を公開して以来、多くの金融機関のお客様 や パートナー様 にご利用いただいてきました。勘定系や顧客チャネル、データ分析基盤といった金融サービスのワークロードについて、AWS 上で FISC 安全対策基準を踏まえたシステム設計を検討する際のガイドやサンプルを提供しています。 今回、その内容を刷新した v2 を GitHub 上で リリース しました。v2 では、コンテンツをエンジニアが読むためだけのものから、エンジニアと AI エージェントが同じように読んで使えるものへと作り直しています。 金融リファレンスアーキテクチャ日本版 の 概要 「金融リファレンスアーキテクチャ日本版」は、金融システムの「高い信頼性が必要なミッションクリティカル領域」の維持と強化につなげていただくためのアセットです。セキュリティとガバナンスの確保、レジリエンスの強化、モダナイゼーションの加速、コンプライアンスへの対応といった、日本の金融機関のエンジニアが向き合う作業を支援するコンテンツで構成されています。 金融リファレンスアーキテクチャ日本版 v2 での進化 金融リファレンスアーキテクチャ日本版 v2 は AIエージェントフレンドリーなコンテンツ提供形態へと刷新し、そのナレッジを Agent Skills (エージェントスキル) の形式で提供します。エンジニアの皆様 に加えて、皆様が利用する AI エージェント や 生成AIツールからも扱えるナレッジへと進化しました。 v2 での主な変更点は次のとおりです。 Agent Skills を中核に据えた提供形態への刷新 31 のスキルをカテゴリ別に収録 サイバーレジリエンスと FSI Lens for FISC のスキルを追加 Webアプリケーションツール「GameDay Plan Generator 」の公開 Agent Skills を中核とした提供形態への刷新 v2 で最も大きく変わったのは、ナレッジの提供形態です。金融システムに求められるセキュリティ、可用性、コンプライアンスの知見を、Agent Skills というオープン標準のフォーマットを利用して提供しています。Agent Skills は、生成 AI を用いた開発ツールが解釈できる形式で手順や設計方針を記述する 仕様 です。同じコンテンツを、設計を検討するエンジニアが読むだけでなく、そのエンジニアが日々使う AI エージェントにも渡して利用できます。 この形式を選んだ背景には、金融 IT の開発現場で AI エージェントや生成 AI ツールの利用が広がってきたことがあります。v2 では、想定する利用者に、金融 IT のエンジニアやアーキテクトに加えて、それらの担当者が利用する AI エージェントや生成AIツールを据えました。設計原則やベストプラクティスを人が読んで理解するだけでなく、設計や開発を支えるAIエージェントにも同じ知識を渡すことで、人と AI の双方の能力を広げることを目的としています。 これにより、構成の検討や設計レビューの場で、AI エージェントが FISC 安全対策基準やリファレンスアーキテクチャを踏まえた回答を返せるようになり、検討の出発点を素早く用意できます。 31のスキルをカテゴリ別に収録 v2 では、v1 で扱ってきたワークロードに加えて、AWS を利用する金融 IT エンジニアの日々の作業を支援するナレッジを含め、現時点で 31 のスキルを収録しています。金融のビジネスワークロードから、それらを支える共通基盤、生成 AI、セキュリティ、情報収集の支援までを一つのカタログにまとめています。主なカテゴリと代表的なスキルは次のとおりです。 コンテンツカテゴリ 主な Agent Skills 金融ワークロード 勘定系（Banking Core）、モバイルバンキング、コンタクトセンター、Capital Marketのオーダー管理、マーケットデータ配信、保険データ分析、クレジットカードイシュア 共通基盤 ガバナンスベース、ハイブリッドクラウド（AWS Outposts）、メインフレーム連携、金融オープン API（FAPI）、データレイク 生成 AI 生成 AI プラットフォーム、生成 AI ユースケース セキュリティとレジリエンス サイバーレジリエンス、ランサムウェア対策、FISC 安全対策基準からのAWS Security Agent セキュリティ要件定義生成、AWS Payment Cryptography 導入ガイド、AWS 操作のセキュリティガード Well-Architectedフレームワーク FSI Lens for FISC 情報収集の支援 AWS 新機能やブログ、セキュリティ情報の取得、日本銀行の統計、金融庁の公表情報、国内のセキュリティ注意喚起の取得 業務支援と汎用ツール お客様固有のコンテキスト管理、Working Backwards によるプロダクト企画、MCP ツールの呼び出し、スキル定義ファイル (SKILL.md) のドキュメントファイル化 全 31 スキルの一覧は、リポジトリの スキル一覧 で確認できます。 v2 で新たに加えたコンテンツ サイバーレジリエンスとランサムウェア対策の スキル 近年のサイバーレジリエンスとランサムウェア対策への関心とニーズの高まりを受けて、レジリエンスのスキルを充実させました。サイバーレジリエンスのスキルでは、論理的に隔離したバックアップやアカウントをまたいだ復旧、ネットワークの自動隔離といったアプローチを扱います。ランサムウェア対策のスキルは、保護、検知、対応、復旧、そして組織としての対応という 5 つのフェーズで整理し、それぞれをサブスキルに分けて提供します。インシデントのどの段階を検討しているかに応じて、必要なスキルだけを AI エージェントに読み込ませられます。 FSI Lens for FISC のスキル FSI Lens for FISC は、AWS Well-Architected Framework を金融向けに拡張し、FISC 安全対策基準に沿って設計を点検するための評価軸 (レンズ) です。運用上の優秀性、セキュリティ、信頼性の 3 本の柱で構成し、各ベストプラクティスには FISC の実務基準の番号を対応づけています。v2 では 2025 年 3 月に公開された第 13 版を元にスキルとして提供し、AIエージェントに渡してレビューに活用することができます。今後、2026 年 3 月に公開された第 14 版をもとにした更新も予定しています。 Webアプリケーションツール GameDay Plan Generator 金融リファレンスアーキテクチャ日本版 v2 は、「Agent Skillsを中心としたAIエージェントフレンドリーなナレッジを提供する」とお伝えしましたが、コンテンツはそれだけにとどまりません。v2 を構成するコンテンツの1つとして、障害対応訓練の計画立案を支援する「 GameDay Plan Generator 」を公開しました。レジリエンスは設計しただけでは十分とは言えず、それを試す訓練があってこそ確かなものになります。このツールは、その訓練の準備にかかる手間を軽減することを狙ったものです。 使い方はシンプルで、AWS CloudFormation テンプレート または 構成図 を渡すだけで、次のものをまとめて生成します。 障害シナリオの一覧と、シナリオごとに「なぜそれを試すのか」という理由 AWS Fault Injection Service の実験テンプレート 訓練中に監視すべき観測ポイントの定義 検知、復旧、影響把握、コミュニケーションの 4 つの軸からなる評価基準 シナリオ一覧やタイムラインを載せた HTML のダッシュボード 生成した結果はダッシュボード上で確認でき、対話しながらシナリオを調整できます。本ツールの特徴は、 Amazon Bedrock を使って、ルール定義だけではカバーが困難な連鎖的な障害や単一障害点を分析し、シナリオを補強する点です。Bedrock を利用できない環境では、ルールベースの生成に切り替えて動作します。訓練計画の初版を短時間で用意できるため、設計から訓練までを一続きの流れとして支える道具として活用いただけます。 まとめ v2 のコンテンツ種類 と GitHub リポジトリ v2 は現時点で、以下の種類のコンテンツを提供しています： 金融ワークロードにおける設計上のポイントやリファレンスアーキテクチャを記述した、ガイダンスとしてのAgent Skills AWSを利用する金融ITエンジニアの日々の作業を支援する、ツールとしてのAgent Skills 特定の用途における金融ITエンジニアを支援する、Webアプリケーション また、v2からは、v1と異なり、複数のリポジトリで そのコンテンツを提供する形になりました。 GitHub リポジトリ： aws-samples/sample-fsi-reference-architecture-jp Agent Skills を提供します。リポジトリをクローンすれば、収録したスキルをそのまま参照でき、対応する開発ツールから AI エージェントに読み込ませることもできます。あわせて、v2のコンテンツ全体を紹介するポータルとしての役割も持ちます。 GitHub リポジトリ： aws-samples/sample-fsi-reference-architecture-jp-gameday-plan-generator   Webアプリケーションツール「GameDay Plan Generator」を提供します。このように、コンテンツによっては個別のリポジトリで公開します。 いずれのコンテンツも v1 と同様に MIT-0 (MIT No Attribution) ライセンスのもとで公開しており、エージェントスキルの多くは日本語と英語の両方で用意しています。なお、収録しているサンプルコードは設計や動作を検証するためのもので、本番環境でそのまま利用することは想定していません。 おわりに 金融リファレンスアーキテクチャ日本版 v2 は、今後も継続的な拡充を予定しています。まずはリポジトリをクローンし、お手元の AI エージェントに関心のあるスキルを読み込ませてみてください。ぜひ、ご質問やフィードバックをGitHub の Issue などでお寄せください。 本ブログ記事は、AWS のソリューションアーキテクト 松原武司 が執筆しました。