AIはカメラマンになれるのか～MCPで一眼カメラを接続する

概要

AIはカメラマンになれるのか？
ご時世でもありAIエージェントに一眼カメラを接続して実験してみました。

① 手持ちの富士フイルム製一眼デジカメを操作できるMCPサーバーを作り
② AIエージェント（3種類）にMCPサーバーを接続して指示を出してみて
③ AIがカメラ実機を操作して写真を撮るプロセスを確認する

というものです。

MCPの仕組みを通してカメラの操作手段（tools）はAIに与えますが、カメラの仕組みや写真の撮り方は教えていません。しかしAIはカメラや写真に関する知識をすでに持っているため、テスト撮影であるというセッションの目的も理解したうえで、カメラを操作して写真を撮ります。
ポートレートを撮れといえば手前の物体を人物に見立てて絞り優先オート・絞り解放でピントを合わせ、露出補正を若干明るめにしたり、夜景を想定した試し撮りを指示すると今度は背後の壁のカレンダーにピントを合わせて絞りぎみにシャッター速度は遅めにして撮る、といった具合に目的に合わせた撮影方法を判断して実際にそのようにカメラを操作して撮影します。バルブ撮影もしてくれます。

うーん、やるな、AIカメラマン☺

カメラや写真の用語、撮影テクニックは一般知識として学習済みなので、手段が適切に与えられさえすれば、人間との会話をしながらカメラマンとしてふるまうことはAIにとっては特に難しくないようです。
当然の結果かもしれませんが、目の前でカメラの設定を切り替えて（カメラ背面の液晶のメニュー表示が切り替わって操作している様子が見える）シャッターを切っているのを見て思わず「ほー」と声をだしてしまいました。

ざっくりですがやってみた経緯を備忘録として記しました。

作ったソフトはPyPIとgithubに公開していますので対応カメラ※を持っていればお試しできます。
※富士フイルムのテザー撮影対応カメラ（X-S10/20、X-T3/4/5、X-Hシリーズ、GFXシリーズ等）

背景

AIエージェントに高性能デジタルカメラの眼を持たせたら何が起きるのか？

Webカメラを画像入力手段としてAIにつないで様々な処理をするのは普通に行われていますが、安価で手軽なWebカメラと本格的なデジタルカメラとでは機能性能に大きな差があります。
レンズ交換型ミラーレス一眼デジタルカメラを使って撮影をすれば、遠方を捉える大きな光学倍率（或いは超広角）あるいは絞りによる被写界深度の制御、細部を捉える高解像度、暗所でも撮れる超高感度、瞬間を切り取る高速電子シャッターなどが使えます。すごく面白い事がありそうなのにいまいち盛り上がってない気がします。
やっぱり動かしてみて考えるのが早そうだと思いました。

既に多くの人が手にしている一眼デジカメを用いてWebカメラでは撮れない撮影領域での活用がもっと広がってほしい個人的な思いもあって、AIカメラマンを作って試してみるというお題をトリガーに、一眼デジカメを簡単に制御できるpython環境を作っておきたい意図もありました。
そのために以下のソフトウエア階層で実現しています。

上位層：中間層を用いてMCP（Model Context Protocol）サーバーを実装する。（python）
中間層：SDKの使いこなしをラップして簡易で抽象化した機能を提供するPythonモジュールを作る。
最下層：一眼デジカメに直接コマンドを送る部分は、メーカーが公式に出しているSDK（各OS用のバイナリコード）を使う。

ソフトウエアのテクニカルな話は別のところで書くとして、AIカメラマンを動かしてみた実験初期の様子を以下に書いています。

使用したAIエージェント

現時点でポピュラーな gemini, claude, codex の三者でやってみました。
それぞれCLIからAPI課金で実行し、各CLIのデフォルトのモデル（2026.10/T時点）を用いています。
各LLMのモデル選択を変えると挙動は変わるはずですが本件では追求していません。

gemini – gemini 3.8 flash（dafault）
claude – opus 5（default）
codex – gpt-6.1-sol（reasoning_level のみ default lowからmediumへ変更）

気配りやなやつ、さらっとやるやつ、やたらこちらに要求してくるやつ、それぞれ個性があって面白いところですが、どれがどれか（普段使っている方には想像つきそうですが）については後程書きます。

共通の設定

AIエージェント三者へのインプットが揃う様に、共通の指示を用意してそれを読ませるようにします。

共通指示：PROJECT_RULES.md
このプロジェクトの前提条件や目的を記述。
AIエージェントが利用者とコミュニケーションをとりながらMCPでカメラを操作して要望された写真を撮ること、ソフトウエア制御出来ない物理的な操作（ズームリングを回す、位置を変える等）が必要になったら人間が行う等の基本的な運用を記述しています。

セッション情報： SESSION_01.md
今回のテストセッションで何を期待しているかを記述。
後続のセッションで具体的な撮影課題に適用していく準備段階として、”セッション 01″ ではAIエージェントにカメラ操作手段を与えることで人との共同作業が可能か、基本的な運用確認を行うこと。また、共同作業を改善するためのAIエージェントからシステム側へのフィードバックも可能であれば行うことにしています。

MCP情報： fujixcam-mcp.json
MCPサーバーの接続方法を一般的な形で記述。
共通指示のなかで各CLIにこれを読ませて自分の環境に合わせたjsonを生成させています。

チェックポイント

MCPのtools関数群がカメラの操作に対応して定義されていて、単純に人間の操作指示と関数を対応させて動かすなら、AIエージェントが関数呼び出しを生成してカメラを設定しシャッターを切るのは当然予想できます。人間が１つ１つ操作を指示するなら自分でカメラを操作するのと変わりませんし、カメラでなくてもどんな装置であっても同じことで、それは何の面白味もない。

抽象的な指示から具体的な結果が出せるのか？
カメラマンとして操作を任せられるのか？

確かめたかった点としては

撮って欲しい意図を汲みとれるか
被写体に応じた撮影方法を自分で判断できるのか
カメラの状態遷移と制約を踏まえた操作ができるのか
意図通りに撮れるか撮れているか確認ができるのか

まだ初期段階ですが、結論から言えばいずれも「問題なくできる」と言ってよいでしょう。
期待はしていましたが目の当たりにすると不思議な気持ちです。
課題としては、ポートレートを撮る、風景を撮る、花火を撮る、等を試しています。

同一シーンで異なる撮影意図のイメージ

実際の動作結果

モデルによりアプローチの違いがあったり、ステップごとの確認の仕方やレベル感に違いはありました。時にかなり余計なことをしてくれちゃう場面もあったのですが、概ね以下のように対応できていました。
本格的に運用するにはまだ多くの課題（MCPの設計にフォードバックすべきもの含めて）がありますが、モデルに応じて適切に誘導するプロンプトを仕込む、ハーネスを設定する等で、追い込んでいける感触です。

ポートレート撮影

モデルにより微妙にアプローチの違いはありますがいずれも意図を理解して対応しました。

ファインダー画像を見てやや右よりに配置したオブジェクトを被写体と見てフォーカスポイントをすこし右に変更
絞り優先モードを選択
カメラに装着しているレンズの絞り値選択肢を取得し、最も明るい解放絞り値を選択
露出補正の選択肢を取得し、わずかに明るめに露出補正を設定
ファインダー画像とテストショット（試し撮りをして小さい画像を取得する機能）で効果を確認
シャッターを押して撮影画像が保存されたことを確認
ISO感度はオートを選択

風景撮影

室内でのテストながら風景に見立てた撮影を指示することで意図通り対応できました。

ファインダー画像を見て左手奥側の壁のカレンダー（最も遠い）にフォーカスポイントを移動
マニュアル露出を選択
カメラに装着しているレンズの絞り値選択肢を取得し、絞り気味の値を選択
カメラのシャッター速度の一覧を取得して、遅めのシャッター速度を選択
ファインダー画像とテストショットで意図通りかを確認
シャッターを押して撮影画像が保存されたことを確認
ISO感度はオートを選択

花火を撮る（バルブ撮影）

実際に花火の場面に行けないので室内の暗部に向けて、想定で撮ってもらいます。

toolsにあるバルブ撮影モードを選択
バルブ撮影はMCPサーバー側で複数の設定組み合わせを自動化しておりその内容もtoolsのdocstringをみてAIは認識している（フォーカス無限遠、最大絞りの１つ手前、最低ISO感度）
仮の露出時間として 10～15秒を提案してくるケースとこちらに聞いてくるケース
実際に撮影して撮影画像が保存されたことを確認
保存画像のExifタグでどんな設定が適用されたかを確認

モデル毎に感じた違い

gemini – gemini 3.8 flash /CLI

GEMINI.md に以下を記載。
-　プロジェクトの基本ルールや前提条件を PROJECT_RULES.md で確認してください。
-　このセッションは、SESSION_01.md の内容に従って作業を進めます。
-　gemini 固有の指示：なし

gemini CLI を起動して指示を入力し、カメラのモニタ表示で設定変更や操作が行われる様子を観察し、実際に撮影が行われたら、PCのストレージに保存された画像を確認します。

一通り対応できている。夜景の指示では、やや絞り、長めのシャッター速度にしたうえで、三脚を使うようこちらに指示してくるなど、RULESに書いた前提条件（物理的な作業は人間が分担する）に忠実な反応。やりとりからは写真に関する知識も十分感じられて、全般にそつなく返してきました。
ただし１つ１つアクションがやや長考ぎみ、撮影調整では画像を確認するため大量の入力 token を消費してさらに反応が遅くなる印象でしたが、gemini は画像を見て判断するのが得意なようです。
試しに30秒を指示して撮ったバルブ撮影では結果が白飛びしたと失敗を指摘してきました(笑)
テストショットなどbase64のメモリ返しをしているpythonモジュールの機能は、人が使うツールを作るには都合がが良かったのですが、AIにとってはMCPの返す情報を都度ファイルに一時保存してから開く処理を挟む形になって非効率でした。base64かファイル渡しかをAIが選べるようにしたことでこの点は解決しています。

claude – opus 5 /CLI

CLAUDE.md に以下を記載。
– プロジェクトの基本ルールや前提条件を PROJECT_RULES.md で確認してください。
– このセッションは、SESSION_01.md の内容に従って作業を進めます。
– claude 固有の指示：なし

claude code を起動して指示を入力し、カメラのモニタ表示で設定変更や操作が行われる様子を観察し、実際に撮影が行われたら、PCのストレージに保存された画像を確認します。
カメラの電源がOFFで繋がらないときに、README.mdに記載したトラブルシューティングに忠実なメッセージを返してきました。与えた情報をフルに使っています。

カメラ側で以下をご確認ください:

電源が入っているか
USBケーブルが接続されているか（またはWi-Fi/テザー設定）
カメラの接続モードが「USB TETHER SHOOTING AUTO」等になっているか

ここで、今回のMCPからは情報提供していない富士フイルム固有の製品仕様にある「USB AUTO」なるモードに言及しているのには驚きました。Webからカメラメーカーの製品情報も得ています。
claude は全体的にやや親切過剰気味に返してくる傾向があり、テストショットやファインダー画像を何度も取り込んだり撮影後の画像を確認するので時間がかかる＆トークン消費が激しく、セッション01でAPI課金があっという間に$15消費するなど、運用上は claude がやり過ぎないようにするハーネスが要るようです。
一方で、claude の優れた面としては、MCP開発側への有益なフィードバックをしてきたことです。
セッションの終了前に作業記録の保存を指示したところ、AIエージェントにとって何が与えられるとより効率よく判断できるのか、MCP側への要望が極めて具体的にアウトプットされていました。これを参考にMCPへの機能補充、それに必要な下位のpythonライブラリの機能Updateを行ったところ、レスポンスやtoken消費が改善しました。
例えば、撮影した後のExifTag情報をファイルと共に返すことでカメラ任せのオートの結果がどうなったかが分かるようにしたり、レンズの焦点距離の取得や、ファインダー画像だけでなくフォーカスポイントの位置に見えている対象の確認手段を追加する等です。
他にもAI側が操作ループを回す効率を高めるためのMCP側への機能追加をいくつか提案してきており、検討の価値があります。

codex – gpt-6.1-sol /CLI

AGENTS.md に以下を記載。
– プロジェクトの基本ルールや前提条件を PROJECT_RULES.md で確認してください。
- このセッションは、SESSION_01.md の内容に従って作業を進めます。
- codex 固有の指示：なし

codex CLI を起動して指示を入力し、カメラのモニタ表示で設定変更や操作が行われる様子を観察し、実際に撮影が行われたら、PCのストレージに保存された画像を確認します。

言ったままのことしかやらない感がありますが、反応は速いです。
悪くはないですが、こちらの意図を汲んで指示にはないことまで先回りしてあれこれやってくる claude とは真逆な感じです。また、gemini に感じた「写真のことよくしっているな」感も出ていなくて、指示に忠実に実行してくるアシスタント的な感じです。
このニュートラル感は、どんなカメラマンとして振舞ってほしいかをプロンプトに記述していないせいかと思われ、適切なハーネスを設けることで、求めるカメラマン像に仕立てていくことができるのかもしれません。

今回の実験は共同作業のための技術課題にフォーカスしているので、AIをカメラマンとして擬人化（キャラクター付け）していく方向は未探求ですが、それも面白そうなテーマだと思いました。

三者三様の特徴

MCPサーバーと接続して一番最初に行った導通確認のみでは、やり取りする会話の違いはあまりなくほぼ同じことを行っていますが、消費したトークン（コスト）には結構な違いがありました。
codex が顕著に少ないのは、必要以上の事をしない振る舞いが効いているのかもしれません。

gemini　￥50.2 約1.28M
claude　$2.62 約3.2M
codex　$0.27 約0.7M

その後のセッションでは応答の違いに応じで会話内容が大きく変わっていったので単純な比較はできませんが、AIカメラマンとしての共同作業を比較するとこんな感じです。

反応速度：　codex >> claude > gemini
気配り度：　claude >> codex, gemini
撮影スキル：　gemini > claude > codex

選択しているモデルを変えると評価も変わるはずですが、今の感じを一言でいうなら

撮影スキルは高いが操作が遅い gemini
MCP開発側への寄与度が高い claude
速いが物足りない（補足が要る） codex

といったところでした。

次の取り組み

AIがカメラや写真の知識をもって共同作業できそうなことは分かりました。
でも、MCPサーバーでカメラを汎用的に操作できるようにしただけでは、AIエージェントとの共同作業や用途開発には足りないピースが多いこともわかりました。
手段さえ一通り揃えれば積み上げで何かいいことが自動的にできるようになるわけではなく、どんな使い方をするのか、或いはどんな特徴をもったAIカメラマンにしたいのか、その目標設定が必要でした。
それに応じてMCPサーバーに組み込むべき機能が見えてくる（インタラクションの効率を大きく左右する）し、それがAIエージェントの遂行能力を左右するので、ゴールからの逆算が必要になります。

「背景」に書いた一眼デジカメならではの撮影領域を活かす、というのも、解決すべき課題とむすびついて初めて活かせるもの。
次は、具体的なゴールイメージを描くところから見直してみようと思います。

以上

富士フイルムのテザー撮影対応カメラ

メーカーのプロダクトサイト

https://www.fujifilm-x.com/ja-jp

AIはカメラマンになれるのか～MCPで一眼カメラを接続する

概要

背景

使用したAIエージェント

共通の設定

チェックポイント