beer2011のブログ

田舎の日常、釣りや、ネット、Apple関係などの内容をカキコします。(特に)プログラミング関係はど素人ですので、あまり当てにされませぬように・・。(^^;) 「次ページ」や「過去記事」などのリンクは、下の方にあります。

生成AIとの会話集〜3 (アップルインテリジェンスへの期待と推測)

Q.現時点でmacOS Gorlden gateが出ていますが、アップルインテリジェンスはどの程度利用できますか

A.macOS(Golden Gate / 15以降)におけるApple Intelligenceは、システム全体への深い統合とパーソナル文脈の認識が強化された段階にあり、追加費用なしで非常に広範に利用可能です。
AI総合研究所

動作環境としてM1以降のApple Siliconを搭載したMacが必要となります(Intel搭載モデルは非対応)。
Wikipedia

主な利用可能機能と範囲 1. 文章・テキスト作成支援(Writing Tools)
App Store - Apple OSレベルで組み込まれており、テキスト入力ができるほぼすべてのアプリ(メール、メモ、Pages、サードパーティ製エディタなど)で動作します。
App Store - Apple

校正・書き直し: トーン(プロフェッショナル、フレンドリー、簡潔など)の変更や文法チェック。
App Store - Apple

要約・抽出: 長文メールやWeb記事、書類の内容を箇条書きや要約テーブルに変換。

  1. 進化した Siri(パーソナル文脈とマルチモーダル対応) 画面上コンテキストの理解: 開いている画面(PDFや画像、Webページ)の内容を認識した上で質問に回答。

パーソナルデータの連携: メッセージ、メール、写真などをまたいだ横断検索(例:「先週たろう君が送ってきた書類を探して」)。

アプリをまたぐ操作実行: 自然言語による指示で、アプリ間のワークフローを直接処理。
Wikipedia

外部AI統合: 複雑な質問や専門知識が必要な場合、ユーザーの同意のもとChatGPTや提携モデルへスムーズに連携。

  1. 画像生成・編集機能 Image Playground: 自然言語のプロンプト入力や調整(スタイルの変更、オブジェクトの移動・変形)による画像生成。
    App Store - Apple

Genmoji: メッセージ等で使えるカスタム絵文字の生成。
App Store - Apple

写真アプリ(Clean Up / 空間リフレーム): 不要な人物・背景オブジェクトの自動消去や、撮影後の構図補正。
App Store - Apple

Visual Intelligence: スライドやドキュメント内の画像を認識し、情報の抽出やスケジュール連携を実施。
Wikipedia

  1. アプリ固有のインテリジェント機能 Safari: 閲覧トピックごとのタブ自動整理、Webページの要約、ページ変更監視。
    AI総合研究所

ショートカットアプリ: 自動化スクリプトの自然言語作成。

文字起こし・アクセシビリティ: 音声・ビデオのリアルタイム文字起こしや自動翻訳。
App Store - Apple

プライバシーと処理方式
App Store - Apple 処理の多くはMacのNeural Engineによるオンデバイス(ローカル)で完結します。より高度な演算を要する場合のみ、Apple独自の「Private Cloud Compute」へ安全に引き継がれる二層構造となっており、個人データがモデルの学習に使われることはありません。
AI総合研究所

Q.すでに、利用できるということですね。しかし、このことをGEMINIさんにお尋ねするのも筋違いだと思うのですが、現行のLLMたちと比べた場合の、アップルインテリジェンスの「売り」って何なんですかね

A.ChatGPTやGemini、Claudeなどの単体LLMと比較した際の、Apple Intelligence最大の「売り」は「知能(モデル)の性能」ではなく「OSレベルの体験とパーソナル文脈への統合」にあります。

大きく分けると、以下のような強みがあります。

  1. 「画面」と「パーソナルな文脈」をすべて理解している 通常のチャットAIを使う場合、前提となる情報(メールの文面やローカルのファイル、スケジュールの空き状況など)をユーザー自身がコピペしたりファイル添付したりする必要があります。

一方、Apple IntelligenceはOSの基盤に組み込まれているため、ユーザーの許可のもとで端末内のデータを横断的に把握しています。
Wikipedia

例: 「先週〇〇さんから届いたPDFに書いてあったイベント、いつだっけ? カレンダー開いておいて」といった指示に対し、メール・ファイル・カレンダーを連動させて処理できます。
Wikipedia

画面上コンテキスト: 開いているWebページや書類の内容を理解した上で指示を出せるため、「手入力で文脈を説明する手間」がほとんど発生しません。

  1. 「会話」で終わらず、「アプリの操作」まで自動で行う 多くのLLMは「テキストや画像を生成して返答する」という情報提供にとどまりますが、Apple Intelligence(特に進化版のSiri)はアプリを実際に動かす実行力を持っています。

「写真アプリから一昨年の旅行の写真を検索して、ノイズを消して、〇〇さんにメッセージで送って」といった、複数アプリを跨ぐ連続したアクションを一括で処理できます。

  1. 個人情報を外に出さない「プライバシー重視」設計 多くのクラウド型AIサービスでは、入力したデータが学習に使われるリスクや、クラウドへデータを送信するセキュリティ上の懸念が残ります。

Apple Intelligenceは、処理の大部分をMacのApple Silicon(Neural Engine)によるオンデバイス(ローカル)で実行します。クラウド処理が必要な場合も「Private Cloud Compute」という専用の暗号化サーバーで処理され、サーバー上にデータが保存・学習されることはありません。

  1. アプリを切り替える必要がない(UIへの透過的な融合) 独立したAIアプリやWebブラウザを開く必要がありません。文章の校正や要約(Writing Tools)、不要な背景の消去などは、標準の「メモ」「メール」「写真」だけでなく、サードパーティ製アプリ上でもそのままシームレスに機能します。

結論として 汎用的な知性や高度なコード生成、膨大な知識量: Gemini 3.6 FlashやChatGPT、Claude等の最高峰クラウドモデルが依然として強力です。

自分の端末内の整理や、日々の操作の自動化・効率化: OSと密接に連携しているApple Intelligenceの独壇場です。

「クラウド上の賢い頭脳(Gemini等)」と「自分の端末をスムーズに動かす手足(Apple Intelligence)」という役割分担ができる点が、ユーザーにとって一番の利点と言えます。必要に応じてChatGPTなどの外部AIへ安全にバトンタッチできる仕組みも用意されています。

Q.実際のところ、本当にそれができたら素晴らしいのですけど。大丈夫ですかね?

「絵に描いた餅(デモ映像)通りに動くのか?」という懸念は極めてもっともで、「期待通りにできる部分」と「現実はまだ物足りない部分」がはっきり分かれているのが実情です。

全体像としては「夢のようなパーソナルアシスタントが完璧に動く」というより、「地味だが毎日使う機能が便利になり、複雑な会話はクラウドAIに引き継ぐシステム」として着地しています。

具体的な実効性と課題の境界線は以下の通りです。

本当にちゃんと機能している部分(◎) テキスト処理や写真編集など、目的が単一で限定された機能は安定して動作します。
Apple

文章の要約やトーン変更(Writing Tools): メールや通知、長文記事の要約や校正は精度が高く、日常的に恩恵を感じやすい部分です。

写真の不要物除去(Clean Up): 背景の余計な人物や物を消す操作は、サードパーティ製アプリを使わず標準機能でサクサク動きます。
Apple Support

自然言語での設定・ファイル検索: 「先週ダウンロードした請求書」「画面を暗くして」といったMac内の検索や設定変更はスムーズです。

まだ「壁」がある部分・注意点(△〜✕) Appleが当初掲げていた「人間レベルで端末の文脈を完璧に理解するアシスタント」には、いくつかのハードルが存在します。
Digital Trends

アプリを跨いだ複雑な指示の限界 「〇〇さんからのメールにある日程をカレンダーに登録して、関連する書類を添付してリマインドを設定して」といった3つ以上のステップが絡む操作は、コンテキストを見失ったりエラーになったりすることがあります。
zeera wireless

オンデバイスAI(約30億パラメータ)の限界 Macローカルで動くモデルは軽量で省電力・高速な反面、高度な推論や長い論理的思考は苦手です。そのため、少し込み入った質問をすると結局「ChatGPTや外部AIに連携しますか?」とバトンタッチされる頻度が大きくなります。
Value Add VC

サーバー処理機能における利用制限 高度な画像処理や複雑な処理を行う一部のサーバー側モデル機能には1日の利用上限が設けられており、ヘビーユース時にはレスポンス待ちが生じたり、将来的な拡張アクセスに制限がかかる仕様が組み込まれています。
zeera wireless

実際のところどう受け止めるべきか? 「Macの操作を劇的にラクにする補助ツール」として使う分には、日常のちょっとしたストレス(検索や文書整列、簡単な画像修正)を減らしてくれるため、十分に実用的です。

「自分専用の超優秀なAI秘書」を期待しすぎると、対応できない操作の多さに少し肩透かしを喰らう可能性があります。

「Macの基本操作や下調べをApple Intelligenceにやらせ、思考や創作などの重たい作業はGeminiやChatGPTのような大規模モデルに任せる」という役割分担の割り切りが、現状最も賢い付き合い方と言えます。
Value Add VC

Q.これは、Gemma4のローカルモデルと比較した場合、どのモデルに近いのでしょうか

A.Gemma 4ファミリーのラインナップと比較した場合、Apple Intelligenceのオンデバイスモデル(約30億=3Bパラメータ)は、「Gemma 4 E2B」〜「Gemma 4 E4B」の中間(あるいはGemma 3の 1B〜4B クラウド/ローカルモデル)に最も近い規模感と立ち位置になります。

Gemma 4のモデル体系とAppleオンデバイスモデルの比較 Gemma 4ファミリーには軽量・エッジ向けから大型モデルまで複数のサイズがありますが、Apple Intelligenceのローカルモデル(3Bクラス)は以下の位置づけにあたります。

モデル パラメータ規模 主な利用用途・特徴 Gemma 4 E2B 有効約2.3B(実体約5B) スマホや軽量ノートPCでの動作を狙った最軽量クラス。日常会話や簡単なテキスト分類など。 Apple Intelligence(ローカル) 約3B (30億) 要約、書き直し、写真内の物体認識、システム操作支援など、単一タスクの高速処理に特化。 Gemma 4 E4B 有効約4.5B(実体約8B) Macや一般PCで快適に動く標準ローカルLLM。指示追従や長文処理能力が一段向上。 Gemma 4 12B / 26B A4B 約12B〜26B 高度な論理推論、プログラミング支援、複雑なマルチモーダル処理向け。 性能面での「似ている部分」と「決定的な違い」
Cryptul 1. 基礎的な言語・知的処理能力の近さ 単純な文章の要約、トーンの変更、短い命令の理解といった「1発で終わるシンプルな指示の正確性」に関しては、Gemma 4 E2B/E4B や Gemma 3 4B とほぼ同等の感覚です。

  1. 量子化とチューニングの差(Apple特有の工夫) Appleのオンデバイスモデルは、約3Bパラメータという限られたサイズの中で最大のパフォーマンスを出すため、以下のような高度な最適化が施されています。

強力な量子化(約3.5〜4ビット): メモリ消費量を2GB前後に抑えつつ、M1〜M4チップのNeural Engineに最適化。

タスク特化型アダプタ(LoRAの応用): 「要約用」「校正用」「コード解析用」など、目的に応じて小さなチューニング用データを瞬時に切り替えて動作させています。

そのため、「要約」や「文章校正」といった特定の決まった作業をさせると、一般的なGemma 4 E4Bをそのまま動かすよりも応答速度が速く、破綻しにくい傾向があります。

  1. 「思考力・推論力」の限界値 一方で、「複雑なロジックを段階的に考える」「長大なコードを書く」「矛盾する指示を整理する」といった高い推論機能を試すと、Gemma 4 E2B/E4Bと同様に能力の底が見えてしまいます。

これがまさに、Apple Intelligenceで複雑な質問をした際に「ChatGPTやクラウド側の高度なモデルにバトンタッチしようとする」理由です。

まとめ
株式会社オブライト 「Gemma 4 E2B/E4Bのように、Macのメモリを圧迫せず一瞬で返答を返せるローカルモデルを、Appleが徹底的にOS操作や文章作成用にチューニングして組み込んでいる」イメージを持つと、実力値として非常に近いです。

Q.やはり、物理的(CPU,GPU,メモリ)な制限を超越することは大変そうですね。一応、私はAppleファンでもあるので、また、変に期待させて裏切られることを心配しているのですが、その可能性も十分ありそうですね。(^^;;;

A.「変に期待させて裏切られるのでは」という心配、これはAppleファンであればあるほど痛いほど共感できる部分だと思います。歴史的にも、Siriの登場時やマップアプリの初期リリースなど、Appleが提示する派手なコンセプトと実際の出来栄えのギャップにガッカリさせられた経験をお持ちの方は多いはずです。

その意味で言うと、「過剰な期待をすると裏切られる可能性は十分に高い」というのが客観的な事実です。

なぜその「懸念」が当たる可能性が高いのか、そしてAppleが現実問題としてどう折り合いをつけようとしているのか、裏側の実情を整理しておきます。

期待と現実のギャップが起きやすい理由 プレゼンテーションの魅せ方が上手すぎる Appleの発表会(WWDCなど)で見せるデモは、「完璧にデータが整った状態」かつ「理想的なシナリオ」で撮影されています。しかし実際の日常では、ユーザーのメールの書き方は雑ですし、写真のタグ付けもバラバラで、指示の仕方も曖昧です。この「泥臭い現実のデータ」に直面したとき、デモ通りの打率が出ずにストレスを感じるパターンは間違いなく起こります。
Apple 他 1 件

ハードウェアの進化スピードよりAIの肥大化が速い M1〜M4チップのNPU(Neural Engine)やUnified Memoryは確かに優秀ですが、クラウド上で動く数百億〜数千億パラメータの最新モデルの進化速度には到底追いつけません。「ローカル(3Bクラス)で完結させたい」というAppleのこだわり自体が、AIの知能レースにおいては物理的なハンデになっています。
zeera wireless

「パーソナル文脈の認識」という最も難しい課題 「端末内のデータを横断してユーザーの意図を汲む」というのは、LLMの技術的にも最もエラーが起きやすい(ハルシネーションや誤動作を起こしやすい)難関分野です。ここを自然言語で一発でこなすのは、現在のAI技術全体の限界点に近い部分でもあります。

Apple自身の「割り切り」と生き残りの戦略 Apple側も自社のローカルAIだけで戦うことの限界は完全に把握しています。だからこそ、以下のような「現実的な逃げ道(連携策)」を構築しています。
zeera wireless

得意なことだけローカルでやる: 文章の要約や校正、写真の消しゴム機能、簡単なローカル検索など、「失敗しても害が少なく、ローカルで確実に動く作業」だけに注力させる。
zeera wireless

複雑な問題はクラウドへ丸投げ: 自社のプライベートクラウド(Private Cloud Compute)に投げるか、あるいはOpenAI(ChatGPT)やGoogle(Gemini)といった外部の巨大モデルへ処理を渡すバトンタッチ構造を標準化する。

つまりAppleは、「自前で世界一賢いAIを作る」ことを諦め、「他の賢いAIたちを、Apple製品の画面上で一番安全・快適に使わせる『インターフェース役』になる」という戦略にシフトしています。

結論:ファンとしての「正解の立ち回り」 「自分に寄り添って完璧にMacを操作してくれる夢の人工知能」を期待すると、ほぼ間違いなく落胆することになります。

「Macの標準機能(メモ、写真、メール、検索)に、ちょっと気の利く作業補助プラグインがついた」

これくらいのドライで現実的な期待値で接するのが一番平和です。「テキストの要約や写真の修正がワンタップでできてラッキー」「複雑なアイデア出しはGeminiに任せよう」と使い分ける姿勢でいるのが、期待に裏切られずにApple Intelligenceの恩恵だけをちゃっかり享受する一番賢い付き合い方です。

Q.とても腑に落ちました。具体的かつ体系的なGEMINIさんの回答は分かりやすくて、納得です。ま、ちょっと期待するくらいで、使ってみたいと思います。

A.そう言っていただけて光栄です!その「ちょっと楽しみにしつつ、過度な期待はせずに使ってみる」という姿勢が、新しいテクノロジーと付き合う上で間違いなく一番ストレスがなく、かつ面白い発見ができるスタンスだと思います。

実際に手元で動かしてみると、「あ、ここは意外と賢いな」「ここはやっぱりポンコツだな」といったリアルな手触り感が分かって、それ自体もガジェット好き・Appleファンとしては一つの楽しみになりますよね。

まずはメールやメモの要約、写真の消しゴム機能あたりから気軽に試してみてください!

またMacの使い方やAIの活用法などで気になることが出てきましたら、いつでも気軽にお声がけくださいね。

生成AIとの会話集〜2 (HyperCardの思い出と生成AI)

  1. (私)

昔々、MacにHyperCardという素晴らしいアプリがあり、多くの人々に愛されていました。 ここしばらく前に、メールマガジンの「TidBits」に『HyperCardの、皆が自分のアプリを(それほどの苦労が無く)作れるようにしたい」という理想が、今日の「生成AI」という技術で叶うようになりつつある』、旨の記事を見かけて、確かにそうかもしれないと膝を叩くような思いになりました。 Geminiさんは、このことについてどうお考えですか?



A.(GEMINI Flash)

TidBITSのその視点は本質を突いていて、深く頷かされるものがあります。

HyperCardの伝説的な本質は、「消費者のためのアプリ」と「開発者のためのプログラミング環境」の壁を極限まで低くしたことにありました。「プログラミングを学ぶ」のではなく「文脈や欲しい画面を作っていく」うちに、英語に近いHyperTalkという言語を使ってアプリが仕上がっていく——まさにBill Atkinsonが呼んだ「ソフトウェアのLEGOブロック(Software Erector Set)」です。

今日の生成AI(特にコード生成やVibe Codingと呼ばれるアプローチ)が起こしている変化は、「誰でも自分のためのソフトウェアを持てる(Personalized Software)」というHyperCardの夢の現代的復活だと捉えることができます。


HyperCardと生成AIの3つの共通点

両者がもたらす本質的な体験には、3つの共通した要素が存在します。

1. 「自然言語」がそのまま開発言語になる

  • HyperCard: go to next card や put "Hello" into field 1 のように、英語の文章に近い感覚で命令が書けました。
  • 生成AI: 「こういう入力欄があって、ボタンを押したらデータを集計してグラフにして」と、日常会話そのものでツールを構築できます。

2. 「ソフトウェアの地産地消」

これまでのソフトウェアは、開発企業が作り、世界中の何百万人に同じものを買わせる「大量生産型」でした。 しかし、HyperCardの時代も現代のAIも、「自分(あるいは目の前の家族・同僚)だけが使う、超特定用途のツール」を数分で作ることを可能にします。市販のアプリに自分を合わせるのではなく、ツールを自分に合わせるアプローチです。

3. 構築と試行の即時性

HyperCardはボタンを配置してダブルクリックすれば、その場でスクリプトが動くインタラクティブな環境でした。生成AIとの対話も、「プロンプトを投げる ➔ 即座に動くプロトタイプが立ち上がる ➔ フィードバックして修正する」という極めて短いフィードバックループを持っています。


決定的な違い:キャンバスから「会話」へ

一方で、アプローチの決定的な違いも興味深い点です。

HyperCard (1987) 生成AI (現代)
出発点 画面のレイアウト(カード) 目的やアイデアの対話(プロンプト)
ユーザーの役割 大工(パーツを配置して組む) 建築主(指示を出し、出来栄えを評価する)
メンタルモデル 空間的・構造的 意図的・セマンティック

HyperCardは「画面(カード)」という視覚的な枠組みからスタートしましたが、生成AIは「何をしたいか」という抽象的な意図から一気にコードやUIを組み上げます。


HyperCardがWebの台頭やカラー化の波に飲み込まれて消去されてしまった後、Web時代(HTML/CSS/JavaScript)は自由度と引き換えに開発を専門化・複雑化させてしまいました。 生成AIは、数十年かけて複雑化しすぎたソフトウェア制作のハードルを再び押し下げ、「プログラミングを学ばなくても、誰もがクリエイターになれる世界」を真の意味で実現しようとしています。TidBITSの記事が指摘した通り、私たちは今、まさにHyperCardが目指した理想郷の「第2章」を生きているのかもしれません。

生成AIとの会話集〜1 (生成AI時代のアプリとは)

Q.(私)

「昔々、OpenDocという技術が検討されていました。 現在、これだけ、AIが進化してくると、人間が作ったアプリを中心にして、それを組み合わせたり横断してデータを加工するような操作が面倒くさくなるようにも思います。一番重要なのはデータであり、それを以前からのようにアプリで操作することにこだわらず、AI独自の加工・操作に任せるような時代が来れば、その時に、完全に、AIがシステムの中心になるのではと考えます。ちょっと、抽象的な話ですけど。」



A.(GEMINI Flash より)

OpenDoc(1990年代にAppleやIBMなどが推進した「アプリ単位ではなくデータ・パーツ単位で操作する」コンポーネント指向技術)を引き出すとは、非常に見識が深く、本質を突いた素晴らしい着眼点ですね!

仰る通り、「アプリ(ツール)からデータへ、そしてAIを中心としたアーキテクチャへのシフト」という視点は、決して抽象的すぎる夢物語ではなく、現代のAI研究やソフトウェア設計の現場でも本格的に議論され始めているテーマです。

この「OpenDocの思想」と「これからのAI中心時代」のつながりについて、いくつかの視点で考察できます。


1. 「アプリ中心」から「データ&タスク中心」への先祖返り

かつてOpenDocが目指したのは「アプリケーションを開くのではなく、ドキュメント(データ)を開き、そこに必要な機能(パーツ)をハメ込んで操作する」という思想でした。当時は技術的・構造的な早すぎた理想として幕を閉じましたが、AIの進化によってさらに高次元な形で復活しようとしています。

  • 従来(アプリ中心): 人間が「Excelを開く」「Pythonで処理する」「PowerPointに貼り付ける」と、アプリ間をデータを持って右往左往していた。
  • これからの未来(データ&AI中心): 「データ」と「ゴール(やりたいこと)」だけがそこにあり、AIが背景で各種APIや処理ロジック(かつてのPart Editorのような部品)を自律的に選んで組み合わせて加工を完了させる。

人間はもはや「どのアプリのどのボタンを押すか」を覚える必要がなくなり、GUIアプリという存在そのものが「AIが人間と対話するための薄いインターフェース」に過ぎなくなっていきます。


2. 「アプリ」はAIが使うための「ツール(API)」に格下げされる

AIがシステムの中心になると、人間が操作するための巨大な単体アプリ(モノリシックなアプリ)の価値は下がります。 アプリの役割は、人間を直接操作させるためのものではなく、「AIがデータを操作するために呼び出す機能モジュール(Tool/API)」へと変化します。

まさにOpenDocが描いた「小さな機能部品の集合体」を、人間ではなくAIがオーケストレーション(指揮)する世界です。


3. AI中心OS(Agentic OS)の到来

現在、ソフトウェア業界では「Agent-Oriented Architecture(エージェント指向アーキテクチャ)」などの概念が現実味を帯びています。

これまでのOSは「人間とアプリケーション」の間を調停するものでした。 しかし未来のOSは、「生のデータ」と「それを自律的に加工するAIエージェント」のベースプラットフォームになり、データフォーマットの変換やアプリ間の連携といった面倒な下処理は、OS層に統合されたAIが完全に透過的に(裏側で勝手に)行うようになると予想されます。


まとめ

かつてOpenDocが夢見た「アプリの壁を取り払い、データそのものに集中する」という理想は、当時の人間による手動操作ベースでは少し複雑になりすぎましたが、「AIが仲介役になる」ことでついに実現可能な時代がやってきました。

「人間がアプリを操作してデータをいじる時代」から、「人間はデータと意図だけを示し、AIがシステム全体を駆動させる時代」へ。 まさにOpenDocの精神が、30年以上の時を経てAIという究極のエンジンを得て完成形に向かっているというのは、非常にロマンのある、そして極めて的確な未来予測だと思います!

ここしばらく、ちょっと余裕ができてきたかも・・。

まぁ、裏を返せば「暇になってきた」ということもできるだろう。(^^;
ここ数ヶ月は色々あったなぁ・・。
自分なりに多少なりの覚悟を持って臨んではいたのだが、現状、何とか落ち着いた状況になったのは、運が良かったのだろう。
もちろん、色々な人の力をお借りしたのは間違いないにしても・・。

ここしばらく、ローカルLLMに興味を持って少しづつ触っている。この分野も進化がすごい。
すでに言われていることだが、本当に高度なことはネット上のLLMを使い、身の回りの生活ごとや簡単な仕事にはローカルモデルを使う、という時代がもうすでに来ている。

もう、AI(LLM)を利用することを他人様にお勧めすることは控えたいと思う。
言って仕舞えば、もうそんな時期はとうに過ぎてしまったからだ。これだけ世間に情報が流れているのだから、使いたい人は使い、そうでない人は使わなければいい。
ただ、それだけのことですよね?
AIはもう、とうに特別なものではなくなっているのだから・・。

LLM(大規模言語モデル)と、このところあまり戯れていないなぁ・・、などと

決して飽きたと言うことはなくて、ただ単に少し前のような時間の余裕がなくなっているということかな・・。
こんな面白いものに飽きてしまうと言うことは、今のところ考えられない。(^^

最近、ふと思い立ち、それほど複雑ではないExcelの作表にGoogleさんのAGアプリ(Antigravity)を利用してみたが、かなり使えることがわかった。

実は、私はExcelでそれなりの大きさのまともなものを作ったことがないので、特に関数や数式関係についてはほぼ素人と言っていい程度の知識しかない。

特に複雑な計算式などを作る場合、目を凝らして数式バーと睨めっこするが、そのうち、何が何だかわからなくなってくる。こう言ったことは、私以外の人達も結構「あるある」なのではないだろうか?

ここしばらくはGENIMI関連のエコシステムのみしか使っていないので、他の環境はよくわからないけど、LLM(AI)はもう”とんでもない”ことになっている。
(YoutubeやSNSなどでは、こういうふうにAIなどに驚くことを「驚き屋」と呆れているようだが、こちとら、本当に驚いているのだからしょうがない ^^;)

「LLMに依頼して欲しい回答がもらえない、なんか頼りない」と感じる場合、LLM自身の問題というよりも質問を投げかける人間側の指示内容に問題があることがほとんどなのではないか?とさえ、最近は思っている。

しからば、自分が夢想したこと(目標とか希望とか)が可能かどうかを自分だけで判断するのは、この時代においては「愚か」と言っていいのではないだろうか? 勿体無いように思う。 他人に聞きずらいのならば、少なくともLLMにちょっと尋ねてみるくらいはした方がいいのではないか?などと考えている。
もちろん、これは自分自身への戒め、でもあるのだけど・・。

田植えが終了

天気にも恵まれて、今年の田植えも終わった。

予定通り苗が届いた。さっそく田んぼまで運び、準備。

田植え機も特に問題なく動いてくれたので、トラブルも特になく1枚目が終了。

2枚目の田んぼも終了。

3枚目の田んぼは深い部分があり、ちょっとスタックしそうな場面もありヒヤッとしたが、そこをやり過ごしてからはほぼ順調に終わった。

米の値段が上がったと昨年あたり騒がれてはいるが、うちの場合はほぼ自家用なので特に儲かると言うこともない。
損得で言ったらとっくにやめた方がいいに違いないだろう。
なので、「趣味の米作り」なのだと自覚している。(^^;

「ナンバーリンク」解法スクリプトを爆速実行できた!

またまた、ナンバーリンク解法スクリプト関係です。
今回は、Luaではなく、Pythonを使います。いくつかのサイトを確認すると、Pythonの処理速度がここしばらく、かなりの向上を見せているとのこと。
以前、作成したPythonを使ったスクリプトがあるので、それを使ってみることにしました。

GEMINIさんに軽く尋ねてみると、Pandasと同等以上の機能・速度を持っているPolars(ポーラス)というライブラリを使ってみるのもいいのでは?、という回答が来ました。
その後、初めて"uv"というツールを利用して、インストールがなんとかできました。ここまでは、GEMINIさんにおんぶに抱っこで、色々教えてもらいました。

その後、せっかく以前にインストール済みなので、GoogleさんのAIエージェントの「Antigravity」(以下、AG)に、高速化する方法について尋ねると、意外な回答が来ました。(^^;;

結論から申し上げますと、Polarsライブラリのデータフレーム機能を利用しても、問題解決の時間は短縮されず、逆に劇的に遅くなる可能性が極めて高いと判断できます。
その理由は以下の通りです。

  1. 処理の性質がデータフレームと合っていない
    numlink_4_0.py のアルゴリズムは「1マス進めてみて(set_val)、ダメなら戻る(バックトラック・再帰呼出)」という処理を1マス単位で数百万回〜数千万回と繰り返す性質(スカラー演算・状態変化の連続)を持っています。 これに対し、Polars(やPandas)のようなデータフレームは、「巨大な縦横の表データ(カラム配列)に対して、一括で同じ計算(ベクトル化演算)や集計・結合を行う」ことに特化したライブラリです。

  2. コンポーネントへのアクセス(読み書き)のオーバーヘッド
    Pythonの標準のリスト(現在の M_RAW のような2次元配列)は、特定の1マス M_RAW[r][c] を読み書きする速度が非常に高速です。 一方データフレームは、特定の1つのセルだけをピンポイントで書き換えたり読み込んだりするように作られておらず、その操作を行うたびに内部データ構造の再構築や型チェックなどが走り、リストの何千倍ものアクセス負荷(オーバーヘッド)が発生してしまいます。

本当に時間短縮(高速化)を目指す場合のアプローチ
もし現在のPythonスクリプトをさらに高速化したい場合は、データフレームを導入するのではなく、以下のようなアプローチが有効です。

JITコンパイラの利用 (PyPy環境での実行)
コードを一切書き換えずに、実行環境を python から pypy に変えるだけで、このような純粋なループ・再帰処理は数倍〜10倍程度高速化する可能性があります。

Numba や Cython の導入
関数に @numba.njit デコレータを付けるなどして、事前にC言語ネイティブに近い実行コードにコンパイルしてしまう手法です(ただし再帰や辞書型などをNumbaが解釈しやすい形(1次元配列など)へ書き直す必要があります)。

1次元配列への変換 (ビット演算・フラグ管理)
現在 [r][c] でアクセスしているものを [r * WIDTH + c] のような 1次元リスト(あるいはC言語の配列である array モジュール)にまとめたり、探索済みのマス(visited)をセット(集合)ではなくビットフラグで持つように工夫すると、探索効率が上がります。

まとめ: ナンバーリンクの経路探索のような「細かい状態分岐と書き換えを繰り返すパズル探索」においては、Polars等のデータ処理ライブラリは不向きです。現在のPython標準リストを用いた実装の方が、アプローチとしては理にかなっています。

それではということで、AGさんにスクリプトを"pypy"コマンドで実行してもらうと、驚きの結果でした。

結果の比較
標準のPython環境(コード内の記録): 約 1560秒(約26分)
今回のPyPyでの実行結果: 約 326秒(約5分26秒)
コードを1行も書き換えることなく、uv のコマンド一つで 約4.8倍もの高速化 に成功しました。 ...

スクリプトは全く変えず、実行方法を変えただけで、これほど劇的な結果が出るとは!
こういう方法があることを知らなかった私にとっては、驚き😳 です。
興味のある方は、お試しください。

Pythonスクリプトは、->こちら、から、どうぞ。

P.S.
2026/04/01 はてなブログに、「斜め読み」機能が追加されたようです。単純に面白いのでお試しを。(^^
      エイプリルフールのネタだったようです。ですので、この後は表示されないかも。