はじめに
AIエージェント（Codex）を利用し、Amazon Rekognitionで写真を解析するiOSアプリを開発しました。
筆者自身はコードを記述していません。
一方、開発中にはAWSとGitHubの認証、ターミナル操作、実機での検証、仕様の判断を
行いました。そのため、単に自然言語で指示を出しただけで完成したわけではありません。
本稿では、開発の経緯と役割分担を整理し、AIエージェントを初学者の学習に利用する
際の利点と課題を考えます。
技術構成と実装の詳細は、以下の記事で紹介しています。
ソースコードはGitHubで公開しています。
なお、今回のアプリはApp Storeでは配布していません。目的は”AIエージェントを使ってみる”だったので、Xcodeから自分の端末へインストールして使用する開発用アプリに留めました。
開発の目的
筆者にはWebアプリの開発経験があり、次の題材としてiOSアプリを作りたいと考えて
いました。また、仕事でAWSを利用しているものの、AI関連サービスを扱う機会がありませんでした。
そこで、次の3点を目的として小規模なアプリ開発を始めました。
- iOSアプリ開発を経験する
- AWSのAIサービスを実際に利用する
- AIエージェントを用いた開発方法を検証する
SwiftUI、iOSアプリ開発、Amazon Rekognitionについては初学者です。事前学習を
終えてから開発するのではなく、まず動作するものを作り、その成果物を教材として
理解を深める方針を採りました。
開発したアプリ
開発したのは、iPhoneで選択または撮影した写真をAmazon Rekognitionで解析し、
検出されたラベルと信頼度を表示するアプリです。
主な機能は以下のとおりです。
- 写真ライブラリからの画像選択
- カメラによる撮影
- 画像の縮小と圧縮
- Amazon Rekognitionによるラベル検出
- 解析結果の表示
- SwiftDataを用いた履歴保存
バックエンドにはAPI Gateway、Lambda、S3、Amazon Rekognitionを使用し、
AWS SAMで構築しました。
人間とAIエージェントの役割分担
今回、Swift、JavaScript、YAMLなどのコードはAIエージェントが作成しました。
設計、実装、テスト、ビルド、ドキュメント整備もAIエージェントが担当しました。
筆者が行った作業は以下のとおりです。
- 開発目的と要件の提示
- ターミナルでのコマンド実行
- AWSとGitHubの認証
- IAM権限の設定
- Xcodeと実機を用いた動作確認
- エラー内容とスクリーンショットの共有
- デザインと仕様に関する判断
- 公開範囲の決定
したがって、「コードを書いていない」ことと「開発に関与していない」ことは
同義ではありません。実装作業はAIエージェントが担当し、人間は目的の設定、権限の許可、動作の評価、仕様の決定を担当しました。
AIエージェントによる作業の範囲
利用前は、ターミナル操作に加えて、生成されたコードをある程度読まなければ
開発を進められないと想定していました。
実際には、必要な認証を行った後、AIエージェントが広い範囲の作業を継続的に
処理しました。
具体的には、AWS側では、SAMテンプレートとLambda関数を作成し、API Gateway、Lambda、S3、Rekognitionなどを利用する環境を構築しました。GitHubでは、認証後にリポジトリを作成し、READMEの整備、秘密情報の確認、コードの公開を行いました。
アプリについても実装だけでなくビルドまで実行されました。筆者はビルドされたアプリを実機で操作し、問題があれば結果をAIエージェントへ報告しました。
コードの断片を提示するだけではなく、実装から検証までを一つの作業として継続した
点が、従来の対話型AIとの大きな違いでした。
開発の進め方
開発は、次の手順を反復して進めました。
要件を伝える
↓
AIエージェントが設計・実装する
↓
実機で動作を確認する
↓
エラーや改善点を共有する
↓
AIエージェントが調査・修正する
たとえば、解析ボタンを押した際に、APIの接続先が未設定であるというエラーが表示されました。エラー内容を共有すると、AIエージェントはXcodeの設定とInfo.plistを調査し、API URLをアプリから参照できるように修正しました。
AWSへのデプロイでも、IAM権限の不足やAWS Budgetsの通貨設定によるエラーが発生しました。この場合もターミナルの出力を共有し、原因の特定と修正を進めました。
初学者がエラーの原因をあらかじめ理解していなくても、発生した事象を正確に共有することで調査を開始できる点は有用でした。
仕様を決めるのは人間
AIエージェントが実装を担当しても、採用する機能や品質基準を自動的に決められる
わけではありません。
デザインの修正
最初に作成されたアプリアイコンに対して、要素と色を減らした簡潔なデザインを指定しました。完成したものを確認し、具体的な修正方針を伝えることで調整できました。
最初の指示だけで完成形を正確に定義する必要はなく、出力を評価しながら段階的に改善できました。
日本語化の取りやめ
当初は、Rekognitionが返す英語のラベルを端末内辞書で日本語化しました。しかし、辞書に存在しない語が英語のまま残り、表示の一貫性を確保できませんでした。
この機能は実装上は動作していましたが、利用時の品質が十分ではないと判断し、英語表示へ戻しました。
実装可能であることは、採用すべきであることを意味しません。最終的な仕様には、実際に利用した人間による評価が必要でした。
最小構成の維持
AIエージェントを利用すると、追加機能を短時間で実装できます。一方、機能の増加に比例して、人間が確認し理解すべき範囲も拡大します。
今回は「Amazon Rekognitionを用いた画像解析を経験する」という当初の目的から外れないよう、機能を限定しました。
AIによって実装速度を上げられても、人間の理解が同じ速度で進むとは限りません。学習目的の開発では、実装可能な範囲ではなく、自分が検証し理解できる範囲を基準に規模を決める必要があります。
権限と認証情報への不安
今回、最も判断が難しかったのは、AWSの権限と認証情報の扱いです。
AIエージェントへどこまで権限を与えてよいのか、APIキーやアクセスキーをどこで管理すべきかについて、初学者が独力で安全性を判断することは困難です。
今回は一般公開するアプリではなく、自分の開発環境で使用するアプリです。
それでもAWS上には実際のリソースが作成されるため、認証情報の流出や想定外の料金を考慮する必要がありました。
今回の構成では、次の対策を実施しました。
- AWSのアクセスキーをiOSアプリへ埋め込まない
- S3バケットを非公開にする
- 一時画像をS3 Lifecycleで削除する
- Lambdaごとに必要なIAM権限を限定する
- 環境固有のAPI URLをGitHubへ登録しない
- 公開前に秘密情報が含まれていないか確認する
- AWS Budgetsで料金通知を設定する
- API Gatewayにスロットリングを設定する
AIエージェントが安全対策を提案・実装できても、権限を許可する主体は人間です。
AIエージェントの実行範囲が広がるほど、与える権限の目的と範囲を確認する必要性も高まります。
不明な権限を求められた場合には、目的、対象リソース、作業後に削除できるかを確認すべきであると思いました。
完成と理解は異なる
アプリは完成しましたが、筆者がSwiftUI、AWS SAM、Lambda、Presigned URLなどを十分に理解したわけではありません。
コードを記述せずに動作する成果物を得られることは、AIエージェントの利点です。
一方、成果物の完成を技術の習得と同一視することはできません。
ただし、自分の要件に基づいて作られ、実際に操作したアプリは、その後の学習教材になり得ます。一般的なサンプルコードと異なり、各機能が追加された経緯や、発生したエラーを把握しているため、コードを読む目的を持ちやすくなります。
従来は、学習してから成果物を作る順序を想定していました。
学習する
↓
理解する
↓
成果物を作る
今回採用した順序は異なります。
成果物を作る
↓
動作と構成を確認する
↓
成果物を教材として学習する
先に成果物が存在することで、学習対象が具体的になります。また、不明なコードや構成について、その場で作成者であるAIエージェントへ質問できます。
学習が進んだ後に関連機能を追加すれば、成果物を継続的な教材として利用できます。
AIエージェントと作った成果物をどう捉えるか
コードを記述していない成果物を「自分で作った」と表現してよいかは、慎重に考える必要があります。
今回、実装の大部分はAIエージェントが担当しました。一方、筆者は目的、要件、公開範囲、品質基準を決定し、実機上で動作を評価しました。
人間が担当した判断には、以下が含まれます。
- 何を作るか
- どの機能を採用するか
- どの機能を取り下げるか
- どの権限を許可するか
- どの範囲まで公開するか
- どの状態を完成とするか
この役割分担を踏まえると、「AIだけが作った」「人間だけが作った」のどちらでもありません。
「AIエージェントと共同で開発した」という表現が実態に近いと考えます。
重要なのはAIの利用を隠すことではなく、どの作業をAIが担当し、どの判断を人間が担当したかを明確にすることです。
初学者の学習に利用する際の留意点
今回の経験から、AIエージェントは初学者の学習開始を支援する手段として有効だと実感しました。ただし、利用時にはいくつかの点に留意する必要があるとも思います。
小さな目的から始める
最初から一般公開できるプロダクトを目標にする必要はありません。特定の技術を一つ試すなど、確認可能な範囲に目的を限定した方が、構成とコードを追いやすくなります。
完成を理解とみなさない
アプリが動作しても、内部の仕組みを理解したことにはなりません。完成後にコード、権限、データの保存先、エラー処理、料金の発生条件をしっかり自分の目で確認する必要があります。
権限を無条件に許可しない
AIエージェントから権限を求められた場合、必要性と対象範囲を確認します。
不明な場合は、許可する前に理由とリスクを質問します。
実装範囲を人間の理解に合わせる
短時間で追加できることを理由に機能を増やすと、検証と理解が追いつかなくなります。
学習目的であれば、人間が説明できる範囲を段階的に広げる方が適しています。
実際に利用して評価する
動作するコードが生成されても、利用時の品質が十分とは限りません。実機で操作し、表示、待ち時間、エラー時の挙動などを確認する必要があります。
完成後のAIエージェントの利用
AIエージェントは、成果物の完成後も学習支援に利用できます。
たとえば、生成されたコードについて次のように質問できます。
このファイルの役割を説明してください。
なぜiPhoneからRekognitionを直接呼び出さないのですか。
このIAM権限をさらに限定できますか。
この処理を初学者向けに順番に説明してください。
次にどの機能を実装すると、現在の構成を理解しやすくなりますか。
自分の理解度に合わせて説明を求められるため、生成された成果物を継続的な教材として利用できます。
まとめ
今回、コードを記述せずに、AIエージェントとiOSアプリを開発しました。
AIエージェントは、コードの生成だけでなく、AWS環境の構築、エラー調査、ビルド、GitHubでの公開、ドキュメント作成まで担当しました。
成果物が完成しても、人間側が技術を理解したことにはなりません。しかし、先に自分の関心に基づく成果物を作ることで、そのコードを学ぶ動機を得られます。
AIエージェントを過度に難しいものと捉える必要はありません。一方で、生成された成果物を無条件に受け入れるべきでもありません。
まず小さく利用し、結果を検証し、理解できていない部分を確認します。この反復が、
AIエージェントを開発と学習の双方に活用するための基本になると感じました。