カテゴリ「Microsoft Copilot」の10件の投稿 Feed

2025年12月20日 (土)

Adobestock_1546995717

OpenAI 社は2025年12月16日に新しい画像生成モデルとしてGPT Image 1.5 を発表しました。この最新の「Image」機能はChatGPTに追加されます。

新しい ChatGPT Images が登場 | OpenAI

これに伴い、Microsoft 365 Copilot でも、画像生成の品質を高めるために2025年12月中旬~2026年1月下旬までに現行の GPT-4o から GPT-Image-1.5 に置き換わることになります。

20251220_195516

しかし、少し前までは画像生成といえば DALE・Eが用いられてきました。が、私自身がその後どうなったのかはっきりと把握できていない。

こうした状況を踏まえて、これまでの OpenAIの画像生成AIの変遷と今回発表された GPT Image 1.5 について整理してみたいと思ったのですが、ChatGPT 5.2 とやり取りしながら調査する中で歴史を語る語り口が面白くなったのでほぼしそのままシェアしてみることにしました。ただし、Nano Banana Pro の影響などに関しては ChatGPT 5.2 だとどうしても OpenAIびいきな調子になるので、Anthoropic 社の Claude Sonnet 4.5 を使って生成しました。

少々誇張した表現や技術的な細かな指摘は横においたとしても、長文ではあるものの、全体的な流れをつかむのには、読み物としてもなかなか興味深かったのでせっかくですから共有します。

ちなみに、少しの「てにおは」レベルの修正や若干の補足情報は追加しています。

//📙ここからが物語の始まり

これまでのOpenAI 画像生成AIの変遷

2019年に人間の脳の神経回路を再現したニューラルネットワークを使用して画像を新しく作成する方法を実証するOpenAIの最初の取り組みとしてImage GPTが登場します。つまりはGPTは画像も扱えるという概念を最初に実験したモデルです。研究目的であり、一般向けサービスではありませんでした。この実験により Transformer が画像にも使えることが証明されました。

DALE・E (2021)

この第1世代は「言語モデルは言葉だけでなく “世界の構造” を理解できるのではないか?」という仮説を画像という分かりやすい形で示すための研究モデルでした。

当時のGPTモデルは文章の続きを予測することに特化しており「犬がボールを追いかける」と書けば、その続きを自然に生成できるレベルに到達していたのです。そこで OpenAI は発想を一段拡張して、「文章の続きを書けるなら、“画像の続きを描く”こともできるのではないか」と考えます。DALL·E は、まさにこの問いに対する実験的な答えだったわけです。

技術的には、DALL·E は テキストと画像を同じ Transformer 系モデルで扱うという、当時としてはかなり大胆な構成を取っていました。画像はピクセルそのものではなく離散化されたトークンとして表現され、テキストと同じように「次に来るトークンを予測する」という形で生成される。つまり DALL·E は、「文章を読む → 意味を理解する → 絵を描く」というよりも、「テキストと画像を一続きの記号列として扱い、その続きを予測する」モデルでした。

このアプローチによって、DALL·E はそれまでの画像生成モデルにはなかった独特の能力を見せました。たとえば「アボカド型の肘掛け椅子」や「宇宙服を着た猫が油絵風で描かれている」といった、現実には存在しない概念の組み合わせを、破綻しながらも“それらしく”表現できたのです。ここで重要なのは、絵の上手さではなく、言語で指定された概念を画像として構成しようとしている点です。

一方で、実用性という観点では明確な限界もありました。生成される画像は解像度が低く、形状や構図は崩れがちで、細部はノイズのようになることが多かったようです。編集や修正といった操作は想定されておらず、「一度生成して終わり」という、完全に研究用途向けのモデルでした。プロンプトも非常にシビアで、少し曖昧な指示をすると、意図とはまったく違う画像が出てくることも珍しくなかったのです。

それでも第一世代の DALL·E が画期的だった理由は、「画像生成AIを作った」ことではなく、GPT 系の言語モデルが、視覚的概念を内包しうることを示した点にあります。DALL·E は、「画像は言語とは別の世界にある」という前提を壊し、「画像もまた、意味を持つ表現形式のひとつであり、言語モデルの延長線上で扱える」という考え方を、はっきりと提示しました。

この意味で、第一世代の DALL·E は、後の DALL·E 2 や DALL·E 3、さらには GPT Image や GPT-5.x の直接の完成形ではありません。むしろ、「この方向は正しい」と示すための、コンセプト実証(Proof of Concept)に近い存在です。品質や使いやすさよりも、思想のインパクトが圧倒的に大きかったモデル──それが、第一世代の DALL·E だったと言えます。

 DALE・E 2 (2022)

第二世代の DALL・E 2 は、第一世代の DALL·E が示した「方向性は正しいが、このままでは使い物にならない」という現実を、真正面から受け止めて作られたモデルでした。言い換えると、DALL·E 2 は思想のモデルから、実用を意識したモデルへの転換点にあたります。

第一世代の最大の問題は明確でした。GPT 的な発想で画像を「トークン列として直接生成」するやり方は、概念的には美しかったのですが、計算量が膨大で品質も安定しませんでした。画像というのはテキストよりもはるかに情報量が多く、ピクセルレベルで次を予測する方式では、どうしてもノイズが多くなり細部が破綻してしまうのです。

DALL·E 2 は、ここを根本から作り直すことを選びます。

最大の転換点は、「画像をそのまま扱うのをやめた」ことです。DALL·E 2 では、画像を一度 潜在表現(latent representation) という圧縮された空間に変換し、その空間上で生成を行います。これにより、モデルはピクセルの細かな揺らぎではなく、「形」「構図」「物体の関係」といった意味的な構造に集中できるようになりました。

ここで初めて、画像生成は「絵を描く」というより、「意味のある構造を組み立てる」作業に近づいたのです。

また、DALL·E 2 では テキストと画像の関係の扱い方も洗練された。テキストをそのまま画像生成に流し込むのではなく、テキストと画像を同じ意味空間にマッピングし、「この文章に最も対応する画像表現はどれか」という対応関係を学習します。この仕組みによって、モデルは単語単位ではなく、文章全体の意味を踏まえて画像を生成できるようになりました。

その結果として、DALL·E 2 の生成画像は、第一世代とは比較にならないほど自然になります。物体の輪郭は安定し、構図も破綻しにくくなり、「それっぽい絵」ではなく、「普通に見られる絵」に近づきました。ここで初めて、ユーザーは「研究成果を見る」立場から、「ツールとして使う」立場に移行し始めたと言えます。

さらに重要なのが、編集という概念が導入されたことです。DALL·E 2 では、画像の一部を塗りつぶして「ここだけ別のものにしてほしい」と指示する インペインティング や、画像の外側を自然に拡張する アウトペインティング が可能になりました。これは、「一発生成して終わり」だった第一世代から、「人間が途中で介入し、やり直せる」ツールへの大きな進化でした。

ただし、DALL·E 2 はまだ「賢いが不器用」な存在でもありました。プロンプトは相変わらず繊細で、言葉の選び方ひとつで結果が大きく変わります。人間が自然に書いた文章をそのまま完璧に理解するわけではなく、ある程度「AIに通じる書き方」を覚える必要がありました。また、文字を正確に描く、複雑な指示を忠実に守る、といった点では限界も残っていました。

それでも、DALL·E 2 が果たした役割は決定的でした。

このモデルによって初めて、「画像生成AIは、研究デモではなく、創作や業務の道具になりうる」という認識が広く共有されました。DALL·E 2 は、画像生成を魔法のような実験から、訓練すれば使いこなせる技術へと引き上げた存在でした。

思想的に見ると、DALL·E 2 はこう位置づけられます。

画像生成は、言語モデルの延長ではあるが、
そのままではうまくいかず、画像に適した表現空間が必要

この判断があったからこそ、後の DALL·E 3 の「言語理解の強化」や、GPT-4o・GPT Image の「再統合」という流れが成立していくことになります。

DALE・E 3 (2023)

第三世代の DALL·E 3 は、第二世代までの流れを踏まえたうえで、「画像生成AIが本当に使いにくい理由はどこにあるのか」を、かなり冷静に見つめ直した結果として生まれたモデルでした。

DALL·E 2 の時点で、画像の品質そのものはすでに「実用レベル」に達してはいました。構図は安定し、物体もそれなりに正しく描けるにもかかわらず、多くのユーザーは満足できていなかったのです。その理由は単純で、「思った通りの絵が出ない」からです。
つまり問題は、絵の上手さではなく、言葉と意図のズレにあったわけです。 

ここで OpenAI が下した判断は、かなり象徴的でした。

「画像生成モデルそのものを、さらに賢くする」のではなく、「人間が書いた自然な文章を、画像生成に適した指示へ翻訳する役割を、GPTに任せる」という設計に舵を切ったのです。

DALL·E 3 は、単体で見ると DALL·E 2 の延長に見える部分もあります。しかし、実際の使われ方はまったく違っていました。ユーザーは、プロンプト職人のように単語を並べる必要がなくなり、「こういう雰囲気の絵を描いてほしい」「この設定で物語の一場面を表現してほしい」といった、普通の日本語や英語で指示できるようになりました。
その文章を受け取った GPT が、裏側で意味を整理し、曖昧さを補い、画像生成に最適な詳細プロンプトへと変換します。そして、その変換された指示を元に DALL·E 3 が画像を生成します。この 二段構えの構造こそが、DALL·E 3 の本質でした。

この設計によって、DALL·E 3 は「画像生成AI」から「会話できる画像生成AI」へと性格を変えました。ユーザーは一回で完璧な指示を書く必要がなくなり、「もう少し明るく」「人物を正面から見た構図で」といった修正を、会話の流れで伝えられるようになりました。画像生成が、初めて 対話的な作業になった瞬間だったといえます。

また、DALL·E 3 では、文章中の複雑な関係性を理解する能力も大きく向上した。複数の登場人物、物体同士の位置関係、スタイルと内容の両立といった点で、DALL·E 2 では破綻しがちだった指示が、かなり忠実に再現されるようになりました。これは、画像生成モデル自体の改良というよりも、「言語理解の質が画像の質を決める」という発見が、設計に反映された結果でした。

思想的に見ると、DALL·E 3 は決定的な転換点を示しています。

画像生成のボトルネックは、
モデルの描画力ではなく、
人間の意図をどう解釈するかにある

DALL·E 3 で起きたことは、「画像生成モデルが賢くなった」ことではありません。「GPT が前に立ち、画像生成を“自分の表現手段のひとつ”として使い始めた」ことでした。

だからこそ DALL·E 3 は、DALL·E 系の完成形であると同時に、「DALL·E という名前が不要になる未来」を予告するモデルでもありました。実際、その後の世代では、画像生成は独立した主役ではなく、GPT の能力の一部として吸収されていくことになるのです。


ちなみに、DALL·E 2とDALL·E 3は現在非推奨となっており、2026年5月12日にサポートを終了する予定となっています。

[参考] Image generation | OpenAI API


GPT-4o Image Generation の登場

2025年3月に GPT-4o Image Generation が登場します。

4o Image Generation が登場 | OpenAI

DALL·E 3 までの進化で、OpenAI はすでに重要な事実に気づいていました。それは、画像生成の品質を決めている最大の要因は、描画アルゴリズムではなく、言語理解の深さだということです。

DALL·E 3 では、GPT が人間の自然な文章を受け取り、それを画像生成に適した形へと翻訳する役割を担いました。この設計によって、ユーザーはプロンプト職人である必要がなくなり、「普通に話す」だけで画像を作れるようになりました。しかしこの時点では、まだ明確な境界が残っていました。
それは「考える GPT」と「描く DALL·E」は、あくまで別の存在であるということです。

ここで OpenAI は、次の問いに進むことになります。

そもそも、
言葉と画像を分けて考える必要は本当にあるのか?

この問いへの答えが、GPT-4o(omni)、そしてその中核機能である 4o Image Generation です。

4o Image Generation が目指したもの

4o Image Generation は、「画像生成モデルを改良したもの」ではありません。それは GPT そのもののあり方を作り替える試みでした。

GPT-4o では、テキスト・画像・音声といったモダリティを、後付けで連携させるのではなく、最初から同じモデルが扱う前提で設計されていいます。モデルにとっては、「文章を読む」「画像を見る」「画像を描く」という行為の間に、明確な切り替えは存在しません。すべてが「意味を持つ情報」として、同じ文脈空間の中で処理されます。

この設計の結果、GPT-4o Image Generation は次のような振る舞いを自然に実現しました。

  1. ユーザーが会話の流れで何かを説明すると、モデルはその意図や背景を理解し、必要だと判断すれば画像を生成する。

  2. 画像は「生成物」というより、思考の途中経過が視覚化されたものに近い。

生成された画像について、すぐに言葉で説明したり修正を加えたりできるのも、この一体設計によるものです。ここで初めて、画像生成は「指示して作る作業」から、「考えた結果として自然に現れる表現」へと変わりました。

DALL·E 3 との決定的な違い

DALL·E 3 と 4o Image Generation の違いは、品質や精度以上に、主語が誰かという点にあります。DALL·E 3 では、「GPT が考え、DALL·E が描く」という役割分担がありました。しかし、GPT-4o Image Generation では「GPT が考え、そのまま描く」。

この差は小さく見えて、実は決定的です。画像生成が「外部ツール」ではなく、GPT の表現手段の一つになった瞬間だからです。

なぜ 4o Image Generation は“完成形”にならなかったのか

体験としての 4o Image Generation は、非常に完成度が高く、ChatGPT の中で使う分には、直感的で、自然で、まさに「未来の AI」でした。しかし、ここで別の問題が浮かび上がります。

業務利用やプラットフォーム提供の観点では、

  • いつ画像が生成されるのか制御しにくい

  • 画像生成コストの境界が曖昧

  • 生成物の保存・監査・責任の切り分けが難しい

といった課題が顕在化しました。つまり 4o Image Generation は、

個人が使う体験としては理想的だが、
業務や API の世界では扱いにくい

という性質を持っていました。

歴史的な位置づけとしての 4o Image Generation

 4o Image Generation の役割は、はっきりしています。それは、「マルチモーダル統合は、本当に成立する」「言語と画像は、同じ思考の中で扱える」ということを、実体験として証明した世代だったということです。

この証明があったからこそ、その後に

  • 画像生成を GPT Image として再整理し

  • GPT-5.x 世代で「統合」と「制御」を両立させる

という流れが生まれていくことになります。

GPT-Image-1

2025年4月に GPT-Image-1が登場します。

GPT-Image-1 は、「画像生成をさらに良くしたモデル」ではありません。それは GPT-4o が示した“理想的な体験”と、現実の業務・API・プラットフォーム要件とのギャップを埋めるために生まれた存在でした。

GPT-4o と 4o Image Generation によって、OpenAI は一つの到達点に辿り着きました。テキスト・画像・音声を最初から一体として扱い、文脈を共有したまま「考えて、必要なら描く」という体験は、確かに成立したのです。これは個人が ChatGPT を使う分には、これ以上ないほど自然で、直感的で、未来的でした。

しかし同時に、別の現実もはっきり見えてきました。

統合しすぎたことによる「扱いにくさ」

GPT-4o の画像生成は、「あまりにも自然すぎた」といえます。

いつ画像が生成されるのかはモデルの判断次第で、どこからがテキスト生成のコストで、どこからが画像生成のコストなのかも境界が曖昧でした。生成された画像をどう保存し、どう監査し、どう再利用するのかという点も、プラットフォーム側から見ると設計しづらいものです。これは 業務用途・API用途では致命的でした。

企業や開発者にとって重要なのは、

  • いつ画像生成が行われるのかを制御できること

  • 画像生成という「重い処理」を明示的に呼び出せること

  • 生成物を成果物として扱い、管理できること

であり、「モデルが空気を読んで勝手に描く」ことではなかったのです。つまり GPT-4o は、

体験としては理想的
設計資産としては危うい

という、ある意味“完成しすぎた”モデルだったといえます。

GPT Image 1 の設計思想

そこで OpenAI が選んだのが、再分離でした。ただし、DALL·E 時代への逆戻りではありません。GPT Image 1 は、GPT-4o が到達した統合的理解を前提として保持したまま、「画像生成という行為だけを、あらためて明示的なリソースとして切り出す」ことを目的として設計されました。

ここが非常に重要なポイントです。

GPT Image 1 は、「画像生成専用で、言語理解が弱いモデル」ではありません。言語理解・世界知識・文脈把握は、すでに GPT-4o 世代で獲得したものを引き継いでいます。

違うのは、使い方の主導権です。

  • GPT-4o:モデルが主導する

  • GPT Image 1:開発者・システムが主導する

この違いが、設計上は決定的でした。

GPT Image 1 がもたらした変化

GPT Image 1 によって、画像生成は再び「呼び出せる処理」になりました。API では、テキスト生成と画像生成を明確に分けて指定でき、「今は文章だけ」「ここで初めて画像を作る」といった制御が可能になりました。

しかし体験の質は、DALL·E 3 時代とは明確に異なります。

GPT Image 1 は単に「文章を画像に変換する」のではなくGPT-4o 世代の文脈理解を前提にしたうえで、画像として表現します。

そのため次のような性質を持ちます。

  • 長い説明文をそのまま理解したまま描ける

  • 抽象的な指示や目的(説明用の図、概念図など)に強い

  • 業務用途の「分かりやすさ」「意味の正確さ」を重視した出力ができる

ここで画像生成は「創作ツール」から「思考や説明のアウトプット形式」へと完全に役割を変えたのです。

なぜ「GPT Image」という名前なのか

この世代で DALL·E という名前が使われなくなったのは、偶然ではありません。DALL·E という名前は、どうしても
「画像を作るAI」「絵を描く専門家」という印象を伴います。

しかし GPT Image 1 は、そうではありません。

それは GPT が考えた内容を、画像という形式で表現するための一つの能力であり、テキスト生成や要約と同じ「出力モダリティの一種」に近いものです。

そのため名前も、

DALL·E(固有名詞)
ではなく
GPT Image(能力名)

になりました。

これは、OpenAI が「画像生成を主役から降ろし、GPT の中に完全に組み込む」という意思を明確に示した瞬間でした。

歴史の中での GPT Image 1 の位置づけ

振り返ると、流れは非常にきれいです。

  • DALL·E:可能性を示した

  • DALL·E 2:実用に近づけた

  • DALL·E 3:言語理解を前に出した

  • GPT-4o:すべてを統合してみた

  • GPT Image 1:統合を前提に、業務向けに再構成した

GPT Image 1 は、「後退」ではなく、統合の成果を社会に出すための翻訳だったといえます。

一文でまとめるなら次の通りです。

GPT Image 1 は、
GPT-4o が示したマルチモーダル統合の成果を、
業務・API・プラットフォームで安全かつ制御可能に使うために再設計された、
“実装のための画像生成世代”である。

GPT-Image-1-mini 

GPT-Image-1 が登場したあと、GPT-Image-1-mini が登場します。リリース時期は明確にアナウンスはされていませんが、利用可能なモデルとしてリストはされています。

GPT Image 1 が登場したとき、OpenAI は一つの答えに到達していました。DALL·E から始まり、DALL·E 2 で実用化し、DALL·E 3 で言語理解を前面に出し、GPT-4o で統合を極限まで押し進めた末に、「画像生成は GPT の能力の一部として再構成できる」という結論に至ったのです。

GPT Image 1 は、その結論を API と業務の世界に翻訳したモデルでした。画像生成はもはや創作のための特別な行為ではなく、説明・設計・思考・業務の一工程として、呼び出されるものになりました。しかし、ここで次の問題が浮かび上がります。

GPT Image 1 は「正確」で「意味に忠実」だったが、重かった。また計算資源もコストも、それなりに要求する。

これは研究や高付加価値用途では問題にならないものですが、画像生成が 日常的に繰り返し当たり前に使われ始めた瞬間この重さは無視できなくなります。

画像生成が「特別」ではなくなったとき

ここが、GPT-Image-1-mini 誕生の本当の背景です。画像生成が珍しかった時代は終わりました。「一枚のすごい絵を作る」ことよりも、

  • 毎日何百枚も生成する

  • サービスの一部として常時呼び出す

  • 完璧でなくてもよいから速く、安定して出す

そういう要求の方が、はるかに多くなりました。これは、画像生成が 実験道具からインフラに変わったことを意味していています。

OpenAI はここで、かつて言語モデルで経験したのと同じ分岐点に立ったのです。GPT-4 のような高性能モデルだけでは、世界は回らない。
用途によっては、「賢さ」より「軽さ」が価値になる。その判断の結果として生まれたのが、GPT-Image-1-mini でした。

Nano Banana Pro の台頭とGPT Image 1.5の登場

※ここからは Claud Sonnet 4.5 を使って文章を作成しています。ChatGPTだとどうも OpenAI への肩入れが大きいようだったので中立性を保つことが目的です。

プロローグ:突然の逆転

2025年という年は、AI画像生成の歴史において、ある種の転換点として記憶されることになるでしょう。長らく画像生成AIの最前線を走ってきたOpenAIが、思いもよらぬ形で追い上げられ、そして応答するという、技術開発における典型的な「攻守交代」の物語が展開されたからです。

第一章:Googleの静かなる反撃

OpenAIがDALL-E 3で画像生成市場を席巻していた頃、Googleは静かに、しかし着実に次の一手を準備していました。その結実がNano Banana Pro(Gemini 2.5 Flash Image / Gemini 3 Pro Image)です。

このモデルが市場に投入されたとき、多くの観測者を驚かせたのは、その圧倒的な多言語対応力でした。特に日本語フォントの処理能力は、それまでのAI画像生成モデルが抱えていた根本的な限界を打ち破るものでした。

技術的背景:なぜGoogleは日本語に強かったのか

この差異の背景には、訓練データの質と多様性という根本的な問題があります。Googleは長年にわたり、Google検索、Google翻訳、YouTubeといった多言語サービスを運営してきた蓄積があります。この膨大な多言語データセットと、それらを処理するための洗練されたパイプラインが、Nano Banana Proの基盤となっていたのです。

さらに重要なのは、Googleが画像内のテキストレンダリングという問題を、単なる「描画」の問題ではなく、言語理解とビジュアル表現の統合という本質的な課題として捉えていた点です。OCR(光学文字認識)技術での長年の経験が、逆に「テキストを含む画像の生成」という逆問題の解決にも活かされたのでしょう。

第二章:OpenAIの危機感

OpenAIはGoogleへの危機感を募らせ「AI業界のトップ」であり続けるために開発計画を変更、ChatGPTのテコ入れを決定したという報道( GIZMODO JAPAN)が示すように、Nano Banana Proの登場はOpenAIに対して深刻な警鐘を鳴らしました。

これは単なる技術的優位性の問題ではありませんでした。DALL-Eの市場シェアが80%減少し、Black Forest LabsのFLUXシリーズが画像生成市場で約40%のシェアを占めるという現実が示すように、OpenAIは複数の戦線で圧力を受けていたのです。

そして、Googleという巨人が本気で画像生成市場に参入してきたことは、OpenAIにとって存亡の危機を意味していました。なぜなら、画像生成AIは単なる技術デモンストレーションではなく、次世代のクリエイティブ産業の基盤インフラとなる可能性を秘めているからです。

戦略の転換:DALL-EからGPT Imageへ

興味深いのは、OpenAIがこの危機に対して「DALL-E 4」という形で応答しなかった点です。代わりに彼らが選んだのは、ネイティブマルチモーダル言語モデルであり、世界に対する視覚的理解を使用して、参照なしで現実的な詳細を含む写真のような画像を生成できる OpenAIGPT Imageという全く新しいアーキテクチャでした。

この決断の背景には、深い技術的洞察があります。DALL-Eシリーズは本質的に「専門特化型の画像生成モデル」でした。それに対してGPT Imageは、GPTの言語理解能力を画像生成に直接統合する、より根本的なアプローチです。これは単なるモデルの改良ではなく、パラダイムシフトだったのです。

哲学的考察:理解と創造の統合

ここで一歩引いて考えてみましょう。画像生成AIとは何でしょうか?それは単に「テキストから画像を作る機械」なのでしょうか?

OpenAIが気づいたのは、優れた画像生成には世界に対する深い理解が必要だということです。例えば「人気の半貴石を入れたガラスキャビネット」という指示に対して、アメジスト、ローズクォーツ、翡翠などを自動的に選び、それぞれの質感や透明度を正確に再現するには、単なるパターンマッチング以上のものが必要です。

これが、GPT Imageが「ネイティブマルチモーダル言語モデル」として設計された理由です。言語理解と視覚生成を分離するのではなく、同一のモデル内で統合することで、より深い概念理解に基づいた画像生成が可能になるという賭けでした。

第三章:緊急出動 - GPT Image 1.5の誕生

OpenAIは当初、次の画像モデルを2025年1月初旬にリリースする予定だったが、タイムラインを加速させたという事実は、この状況の切迫性を物語っています( Interesting Engineering)。

2025年12月16日、GPT Image 1.5が発表されました。GoogleのバイラルなNano BananaモデルへのCode Red(緊急事態)レベルの対応として、OpenAIがGPT Image 1.5を正式にリリースしたのです。

技術的進化:速度と精度の両立

GPT Image 1.5の最大の特徴は、前モデルと比較し、生成速度が最大4倍に向上したことです。しかし、これは単なる計算速度の向上ではありません。

画像生成における「速度」とは、創造的プロセスそのものの性質を変えるものです。4倍速いということは、同じ時間で4倍の試行錯誤ができるということ。つまり、人間の創造的思考のペースに、AIがようやく追いついたのです。

さらに重要なのが「精密編集」機能です。GPT Image 1.5は「精密編集」を導入し、顔の類似性、照明と構図、ブランドの整合性を保持する 能力を獲得しました。

技術的深層:状態の保持という革命

従来の画像生成AIは、ある意味で「記憶喪失者」でした。新しい指示を受けるたびに、前の画像のことは忘れてしまう。「赤いセーターを青に変えて」と言っても、セーター以外の全てが変わってしまうのです。

GPT Image 1.5が実現したのは、画像の意味論的構造を理解し、その一部だけを操作する能力です。編集時に構図・ライティング・人物の見た目などが保たれやすい点を強調しており、マーケティング用途ではロゴやブランド要素の保持にも言及しています。

これは技術的には、画像を単なるピクセルの集合ではなく、階層的な意味構造として理解していることを意味します。「この領域は人物の顔」「この部分は背景の照明」「これはブランドロゴ」といった意味的な分節化を内部表現として持ち、それぞれを独立に操作できるのです。

第四章:残された課題 - 日本語という試金石

しかし、すべてが完璧になったわけではありません。検証結果は厳しい現実を示しています。

Markdown形式で指定した表組をChatGPTで画像にしたものは日本語のフォントが正確ではないのに対し、Geminiで画像にしたものはフォントは完璧です。この比較は、Googleの優位性がまだ健在であることを示しています。

なぜ日本語は難しいのか

この問題は、一見すると些細に思えるかもしれません。しかし実は、AI画像生成の根本的な課題を浮き彫りにしています。

日本語フォントが難しい理由は、単に「訓練データが少ない」という量的な問題ではありません。日本語の文字体系は、以下の複雑さを持っています:

  1. 文字種の多様性:ひらがな、カタカナ、漢字、そしてアルファベットが混在する
  2. 視覚的複雑さ:漢字は画数が多く、細部が重要(「土」と「士」の違いなど)
  3. 文脈依存性:同じ文字でも、フォント、サイズ、配置によって可読性が大きく変わる

つまり、日本語フォントの正確な生成は、AIが視覚的詳細をどれだけ精密に制御できるかを測る、優れた試金石なのです。

指示追従性というトレードオフ

興味深いことに、指示追従性に関してはChatGPTの方が優れているのではないかという評価もあります。つまり、Googleは美しい日本語を生成できるが、時として「余計なもの」を描いてしまう。OpenAIは日本語は苦手だが、指示に対しては忠実だということです。

これは深い技術的ジレンマを示唆しています。創造性と制御性のバランスという、AI開発における永遠の課題です。

過度に創造的なモデルは、美しいものを生み出すかもしれませんが、ユーザーの意図からは逸脱します。過度に制御されたモデルは、指示には忠実ですが、柔軟性や美的センスに欠けるかもしれません。

第五章:パラダイムの変化 - 専門モデルから汎用知能へ

DALL-Eの終焉は象徴的です。DALL·E 2とDALL·E 3は現在非推奨となっており、2026年5月12日にサポートを終了する予定 OpenAIという決定は、OpenAIの戦略的転換を明確に示しています。

専門化 vs 統合化

AI開発には、常に二つの相反する哲学が存在してきました:

  • 専門化アプローチ:特定のタスク(画像生成、テキスト生成、音声認識など)に特化したモデルを作る

  • 統合化アプローチ:すべてのモダリティを扱える汎用モデルを作る

DALL-Eは前者の極致でした。画像生成に特化し、その分野で卓越することを目指しました。しかし、GPT Imageは後者の道を選びました。

この選択の背景には、マルチモーダルAGI(汎用人工知能)への長期的ビジョンがあります。人間の知能は、言語、視覚、聴覚、触覚などを統合的に処理します。それらを分離した専門モデルで扱うのではなく、統合されたモデルで扱うことが、真の知能への道だとOpenAIは賭けたのです。

第六章:競争がもたらす進化

この物語から何を学ぶべきでしょうか?

OpenAIとGoogleの競争は、一見すると企業間の覇権争いに見えます。しかし、より深いレベルでは、これは技術進化の加速装置として機能しています。

Nano Banana Proがなければ、GPT Image 1.5の開発スケジュールは加速されなかったでしょう。Googleの挑戦がなければ、OpenAIは現状に満足していたかもしれません。

弁証法的発展

哲学者ヘーゲルの弁証法になぞらえるなら:

    • テーゼ(正):OpenAIのDALL-E 3による画像生成市場の支配

    • アンチテーゼ(反):GoogleのNano Banana Proによる多言語対応の優位性

    • ジンテーゼ(合):GPT Image 1.5による速度、精度、統合性の追求

しかし、これは終わりではありません。おそらくGoogleは次の一手を準備しているでしょう。そしてOpenAIも、日本語フォント問題を含む残された課題に取り組んでいるはずです。

エピローグ:終わりなき進化

2025年という年は、AI画像生成が「技術デモ」から「実用ツール」へと移行した年として記憶されるでしょう。生成速度が最大4倍に向上し、指示に対する忠実度とテキスト描画能力が大幅に進化したことで、クリエイターたちは初めて、AIを真剣な創造的パートナーとして扱えるようになったのです。

しかし、日本語フォントという「些細」な問題が示すように、完璧にはまだ遠い道のりがあります。そして、それでいいのかもしれません。

なぜなら、技術の進化とは、完成ではなく継続的な改善のプロセスだからです。OpenAIとGoogleの競争は、ユーザーである私たちに利益をもたらします。それぞれが相手の強みを学び、自らの弱点を克服しようとする限り、技術は前進し続けます。

DALL-Eの終焉は、終わりではなく、新しい始まりです。専門モデルの時代から、統合マルチモーダルモデルの時代へ。そして、その先に待っているのは、おそらく私たちがまだ想像もできない、新しい形の創造性なのでしょう。

2025年12月11日 (木)

先日(2025/12/8)に実施したMicrosoft 365 SharePoint 勉強会の第2回目の資料と録画を公開しています。

2回目のお題は OneDrive (Business) の基礎と最新情報です。

Microsoft 365 Copilot などによる AI エージェントが組織に導入される際に欠かせないのがドキュメント管理であり、その基盤の一つが OneDrive です。同期の話やAIエージェントの今後の展望も含めて説明しています。

今後も不定期で勉強会(無料)を行っていく予定です。ご興味のある方は下記 Connpass のページをご参照ください。

Microsoft 365 SharePoint 勉強会 - connpass

録画

スライド

先日(2025/10/31)実施したMicrosoft 365 SharePoint 勉強会の第1回目の資料と録画を公開しています。

初回のお題は SharePoint ナレッジエージェントです。 SharePoint でのナレッジマネージメントに関して機能の紹介だけでなく、今後、ナレッジマネージメントの基盤を十分に管理をしていくうえで何学んでおくべきかについても、弊社で行っている研修を含めご紹介しています。

今後も不定期で無料の勉強会を行っていく予定です。ご興味のある方は下記 Connpass のページをご参照ください。

Microsoft 365 SharePoint 勉強会 - connpass

録画

(補足) 勉強会中に説明している「SharePoint Premium」 は現在、「Microsoft 365 ドキュメントのドキュメント処理」という名称に変わっており、名称自体がいつの間にか消滅しているようです。その前の名称の SharePoint Syntex はまだドキュメントに記載が一部残っています。 なお、11月にはSharePoint ナレッジエージェントは2026年初頭に Microsoft 365 Copilot に全機能を含めるという発表がありました。

スライド

2024年6月 4日 (火)

先日の Microsoft Build 2024 で SharePoint サイト内の複数のファイルなどからカスタム Copilot を素早く作成できるようになることが発表されました。

これから紹介する機能が一通り利用できるようになるのは 2024年の夏ごろになるということで、現在、プライベートプレビューです。

📌プライベート プレビューのエントリー
https://aka.ms/TryCopilotsSharePoint

SharePoint をベースとした Copilot 登場の背景

SharePoint は多くのコンテンツが蓄積され続けています。コンテンツのリポジトリが増え続ける中、より正確な情報に基づいて回答を得たいと思ったときにどうすればよいのか。また知識をほかの人と共有するにはどうしたらよいか悩むところです。

これまでは何か仕事を行うために必要な情報を自らかき集めてくる必要がありました。ですが、AI の力を借りて素早く必要な情報を集め、私たちは自分の行うべき仕事に専念できるようになる。そんな未来を描きつつ、新たに登場するのが数クリックで「 SharePoint からのカスタム Copilot の作成」できる機能です。作成した Copilot は、Teams チャットやメールなどで他のユーザーと共有できます。

この記事について

Microsoft Build 2024のオープニング Keynote で Jeff Taper 氏がこのことについて話しています(1:07頃から)。

この記事では、Keynote と TechCommunityで発表された内容および Microsoft Build 2024 BKR144 の内容を日本語でまとめていきます。

各SharePointサイト (OneDrive含む) で利用できるビルトインの Copilot

SharePoint のサイト所有者はそのサイトのコンテンツを範囲とするビルトインの Copilotを有効化できるようになります。

Sharepoint_builtin_copilot

このビルトインの Copilot はサイト内の情報をもとに回答を生成してくれます。たとえば、マーケティングチームが新しい製品のラウンチに向けて資料などをSharePoint サイトに格納しているとします。そこには、デモビデオ、スペックシート、プレゼンテーション資料、プレスリリースなどが含まれています。このサイトの Copilot は「この製品のラウンチ日は最終決定したの?」などと尋ねるとこうしたサイト内の情報をもとに信頼性の高い回答を返してくれるのです。

ちなみに、Copilot は回答する際にそのサイトのコンテンツ内から情報を得ますが、ユーザーのアクセス権限に基づいて取得するため、ユーザーにとってはその人が閲覧可能な情報から回答が生成されるということです。

Copilot の既定のスコープはそのサイトです。ですが、この範囲を広げたいということもあるでしょう。サイトの所有者として Copilot をカスタマイズできます。 Microsoft Copilot Studio または Visual Studio で作成した Copilot をサイトの既定の Copilot として指定することもできます。

つまり、ビルトインの Copilot独自にカスタマイズする Copilot2つがある。この2つの違いについては Build の BRK144セッションの資料がわかりやすくまとまっています。

Integrating your bots and Copilot experiences natively into SharePoint and Viva | BRK144

20240525_105830

日本語にして少し加筆すると次のようになるでしょう。

harePoint サイトごとのCopilot 自分で選択したコンテンツから作成した カスタム Copilot
サイト用のビルトイン Copilot サイト用にカスタム Copilot を作成したもの
サイトのコンテンツが基盤で、すぐに利用を開始できる 自分で選択したコンテンツが基盤
カスタマイズ可能 左と同じ
Teams やメールなどを経由して Copilot を他のメンバーと共有できる。そのため同僚は同じナレッジベースを使って仕事ができ、リアルタイムにコラボレーションできる 左と同じ
自分のコンテンツのアクセス許可レベルはそのままで応答できる (各ユーザーにとって閲覧権限がなければ、その情報は使われない) 左と同じ
サイトの所有者は自サイトのCopilotを制御できる。 -

誰でも数クリックで SharePoint から Copilot (拡張) を作成できる

サイトの所有者やサイトの管理者だけでなく、サイトの編集権限を持つ人(サイトメンバーなど)であれば、数クリックでサイトの Copilot を作成できます。SharePoint からカスタムのCopilot を作成できるので、特定のプロジェクトなどの特定の目的の専用 Copilotを手軽に用意できます。

20240528_213138

次のスクリーンショットは Microsoft Build 2024のオープニング Keynote 内でのデモ画面です。配達ドローンのラウンチを行うサイトで、ライブラリ内の複数のファイルを選択してコマンドバーから「Create a copilot」をクリックしています。

20240523_182022

次の画面ではこれらのファイルが含まれているフォルダー名と同じ Final Maetrials Copilot という名前で Copilotが生成されるのがわかります。

20240523_182102

ということで、本当に数クリックで Copilot ができてしまいます。この画面からすぐに使う場合は「Try it」、編集する場合は「Edit」をクリックします。

このように作成することで SharePoint サイトの右側でカスタム Copilot がすぐに利用できます。

ちなみに、この Copilot のソースファイルも画面上のドキュメント ライブラリに作成されていることがわかります(ReleCloud_Delivery_Doron.copilot)。

20240524_185320

なお、 Copilot の右上の … をクリックすることで既存の Copilot の共有、編集が行えるだけでなく、新しいチャットを開始したり、チャット履歴を確認することもできます。

20240526_145952

Copilot の設定

SharePoint に Copilot が展開されると、サイトの設定メニューに「Site Copilot Settings (サイトのコパイロットの設定)」が新たに追加されます。

20240525_112136

この設定からこのサイト上でユーザーが利用できる Copilot を選択できます。既定の Copilot を指定するのではなく、複数利用可能な Copilot がある場合に、そのうちのどれをユーザーが利用できるかを決めるということです。

実際には次の図のように Copilot の切り替えができるようになるようです。20240524_201753

Copilot の共有

作成した Copilot は共有できるのですが、結局のところCopilot の共有とは、ライブラリ内に作成された*.copilot であり、このファイルの共有リンクを作成することですね。SharePoint ではおなじみの共有方法です。

20240524_190302

たとえば、この共有リンクは Microsoft Teams のチャットに貼り付けられます。追加するとメンバーもこの Copilot と対話できるようになります。20240524_190424

アクセス権はどうなる?

ビルトインの Copilot と同様に、カスタム Copilot は既存の SharePoint のアクセス許可レベルに従います。カスタム Copilot のファイル自体の共有は共有リンクで行いますが、コンテンツに関してはすでにアクセス権限を持っている必要があり過剰共有の問題はおきません。

Microsoft Copilot Studio との統合

Copilot for Microsoft 365 ユーザーは Copilot Studio の使用権を持っています。ですから、組織内での利用に関しては追加料金がかかることなく利用できます。

次の画面はMicrosoftが発行しているライセンスガイドの一部です(2024年4月のP19)。単体の Microsoft Copilot Studio のサブスクリプションと比較すると機能は限定的ですが社内利用に関してはほとんどの機能が利用できることがわかります。20240604_112802

基盤としてSharePoint 以外に拡張する必要がある場合は、 Copilot Studio からデータソースを追加できます (※現在、1,000種類以上のデータコネクターがある)。Copilot for Microsoft 365 であれば、Copilot Stduio 内でプレミアムコネクターやカスタムコネクターも利用できます。

既存の Copilot を Copilot Studio で編集するには Copilot の編集画面でSource タブまたは Behavior タブをクリックすると下部に表示される「Add advanced customiztion in Copilot Studio」をクリックします。

20240524_194023

画面上部に次のようなメッセージが表示されます。

Your SharePoint copilot extension is ready for editing. Once you choose Create, any additional edits to this copilot can only be made in Copilot Studio.

つまり、SharePoint copilot 拡張を編集する準備ができたので右上の「Create」ボタンが押せます。ただし、一度この Create ボタンを押せば、今後は Copilot Studio 内からしか編集できないようになるということです。

20240526_102744

Copilot Studio では編集にフル機能を使えます。20240526_151540

たとえば、ナレッジベースを追加する場合はDataverse データベースやパブリック Web サイトなども追加できます。これらは Copliot 用のコネクターを通じて行えます。

※ Copilot コネクターのプレビューへのアクセスは2024年6月より開始されます。20240526_102808

またアクションも追加できるようになっており、特定のコネクターのアクションの追加や新規フローの作成などもできるようになっています。一通りの設定が終わったあとは[Publish]ボタンから発行するだけです。

20240526_102914

Microsoft 365 Copilot アプリでの利用

Microsoft 365 の Copilot アプリでもカスタム Copilot として利用できます。この場合は、自分で作ったカスタム Copilot や自分に共有されている Copilot は、自分が最近使った Copilot 拡張の一つとして表示されます。

20240524_192424

最後に

ここまで、これから利用できるようになる SharePoint のサイトをベースにした Copilot やカスタム Copilot 作成について説明してきました。

SharePoint サイト内に共有されている情報を生成AIを使って有効に利活用できるようになります。従来のファイルサーバーでは格納される情報が増大するほど埋もれがちでしたが、Copilot と SharePoint の組み合わせで、SharePoint 内でユーザーが作成した様々なデータだけでなく外部のデータも組み合わせて有効活用できるというのは画期的だと思います。

いよいよ、新しいナレッジマネージメントの姿へと進んでいくという側面としてもとらえられそうです。

2024年5月 7日 (火)

Excel の Copilot を使うと1回のプロンプトで複数の数式列候補を生成できます。 

たとえば、名前が含まれている列で空白を挟んで姓と名が分かち書きになっているとき、「名前の列を姓と名に分割してください」とプロンプトすると姓と名の二つの列を生成して分割する式を提案してくれます。 20240507_142435

ただし、対象は必ずテーブルになっていなくてはいけません。

また特定のテーブルや列を指定するときにはメンションする必要があるとのことで、この場合は列ですから @列名 を指定しないとうまく回答してくれません。


YouTube: Microsoft Copilot in Excel: 数式列を提案する