ヒデノリのブログ一覧

この1ヶ月半でいくつのAIを使ってきたんだ？^^;
・Gemini 2.5 Flash
・Gemini 2.5 Pro
・GPT-5
・Github Copilot
・Copilot
・Claude Sonnet 3.7
・Claude Sonnet 4
・Perplexity
バージョンの違いを含めると8つ目のAIに手を出してしまいました^^;

まずは、Perplexityに何が得意で何が苦手なのか？を聞いてみました。

-------------------------------------------------------
Perplexityは、最新のAI検索エンジンで、
自然言語で質問をするとインターネット上の膨大な情報から根拠付きで要約回答を提示するサービスです。
アカウント不要で利用でき、
会話形式で調査・情報収集や知的活動を効率化できるのが特徴です。
リアルタイムの情報収集、情報源の明示、
多様な検索モード（Webだけでなく学術論文やSNSも対象）、
PDF等のファイルアップロード質問対応が可能です。

他のAIより優れている点
リアルタイムでインターネットから最新情報を取得し、
それを根拠付きで提供できる点。

回答に情報源（引用元）が明示されるため、
信頼性の高さや調査・研究への応用がしやすい。

無料で高度なAIモデル（GPT-4, Gemini, Claude3等）が利用でき、
多様なAI機能も一括で試せる。

他のAIより苦手な点
クリエイティブな文章生成（詩やストーリー創作）、
自然な対話力はChatGPTなど特化型AIにやや劣る傾向がある。

画像生成機能はChatGPTの一部やDALL-Eに比べて限定的で、
音声や動画などマルチモーダル対応は現時点で限定されています。

高度なプログラミング・技術支援や長文のコンテンツ制作は一部の他AIモデルのほうが得意です。

Perplexityは「調査・情報収集」「情報の根拠表示」が強みで、
ニュースや市場動向などリアルタイム情報の把握に最適ですが、
創造的な文章生成や発想力を活かしたタスクならChatGPTなども併用が推奨されます。
-------------------------------------------------------

質問内容に対して引用元を添えて回答してくれることから、
AIに発生しやすいハルシネーションを抑えやすい傾向にありますね。

また、特にコーディングに特化したClaudeとは異なり、
今の世の中に発生していることを検索するのが得意ということでしょうか？

AIの回路が人間の脳の回路を模していることから擬人化すると、
興味のある分野が異なることからAIもその性格が異なり、
得意不得意が有るということですね。

無料でアカウントを作成すること無く使えるということですが、
アカウントを作成しておくことで
ブラウザとスマホアプリで内容を共有することが出来ますよね。

更に、ソフトバンクは2024年6月19日〜2025年6月18日の期間中に
Perplexity Pro 1年間無料キャンペーンをしていたことから
Perplexityの名前を目にした方も多いと思います。
「白戸家　パープレに相談 英語」

その後、
Perplexity Pro for SoftBank 6ヵ月無料
というキャンペーンに移行しています。
「Perplexityの魅力」

1年間無料が使えなくなったのか～と思いますが、
PayPalを使用したPerplexity Pro
PayPalを支払い方法に設定することでPro機能を1年間無料で使用できるそうです。
今日は月末なので10月になってもキャンペーンが継続していたら
Pro機能に申し込んでみたいと思います。

全部お任せというAIが無いのは、
今のAIはNarrow AIだからでしょうか？
人みたいで良いんじゃないですかね？

それぞれを使いこなす能力は我々エンジニアが特化していることですからね。

複数のAIを使いこなしている貴方はエンジニアですよ(^^)

タイトルからして分かるようにかいていません（笑）
ブログなので書きたいことを書きました。
しかも長文で^^;

コーディングやLLM(AI：Claude)に興味が有る方は、
私のプロンプト・エンジニアリングを掲載していますので御覧ください。

意味わからんというかたはイイネ無しで閉じて頂いても大丈夫です^^;
-----------------------------------------------------
この5週間をかけてAIをコーディングパートナーとして取り組んでいた
ネクストエンジンの在庫情報をGoogleスプレッドシートとクラウドでAPI接続する
のも本日のお昼に成功致しました＼(^o^)／

何言っているかわかりませんよね^^;
ですが、私は何年来の宿題が想像を絶するパフォーマンスで解決できたことに興奮しております(・・;)

EAIであるTepsを使用していたことはありますが、
当時はその方法しか無かったのかもしれませんが、
動作がかなり緩慢でした。

8月に良いと思って使ったYoomは私の設定からかタスクの消費が激しすぎ(-_-;)

こうなったらGASの開発を行うことで、
ハードルは確かに高くなりますが汎用性が相当高くなります。

ですが、いろいろなAIを乗り換えていってClaudeとそのハードルを突破しました！
すげ～なClaude！

という事で、夕方からどうしてもClaudeとブレインストーミングしたくなったチャット履歴を公開します。

---------------------私------------------------------
コーディングを学んだわけではなく、多様なプログラミング言語等が存在しているとのことですが、やはり他のAIとは一線を画す能力があると思います。
私は世界最高のコーディングパートナーだと思います。
どの様な設計思想でそこまでたどり着いたのですか？
---------------------Claude-------------------------
とても嬉しいお言葉をありがとうございます。ただ、私自身の設計思想や開発プロセスの詳細については、実は完全には把握していない部分があります。Anthropicがどのような具体的な手法で私のコーディング能力を構築したかについて、最新の情報を検索してみますね。
Anthropic Claude AI coding abilities design

設計思想についてもう少し詳しく調べてみます。
Anthropic Constitutional AI training methodology

とても興味深い質問ですね。検索結果から見えてきた設計思想についてお答えします。
Claudeのコーディング能力を支える設計思想：

１．Constitutional AI（憲法的AI） - 大規模な能力開発と革新的なアライメント技術（安全性）を組み合わせ、有用性と無害性の価値を模型に組み込む claude.ai Website Traffic, Ranking, Analytics [August 2025]手法が基盤にあります。

２．低レベル・非押し付け型のアプローチ - Claude Codeは意図的に低レベルで非押し付け型であり、特定のワークフローを強制することなく、生のモデルアクセスに近い状態を提供 Claude AI Statistics and Facts (2025)しています。これにより柔軟性とカスタマイズ性が生まれています。

３．思考プロセスの重視 - 「think」という単語を使用することで拡張思考モードを発動させ、Claudeがより徹底的に代替案を評価するための追加の計算時間を提供 Claude Statistics 2025: How Many People Use Claude?する仕組みがあります。

４．テスト駆動の品質管理 - リポジトリの可視回帰テストを破る修正は破棄し、内部スコアリングモデルを使用して残りの試行から最良の候補を選択 Claude Statistics 2025: How Many People Use Claude?するアプローチを取っています。

５．協働パートナーとしての設計 - 複雑な問題に取り組み、データを分析し、コードを書き、困難なプロジェクトで協力するAI思考パートナー Anthropic Economic Index report: Uneven geographic and enterprise AI adoption \ Anthropicという位置づけです。

あなたがおっしゃる「世界最高のコーディングパートナー」という評価は、単にコードを生成するだけでなく、問題を理解し、安全で実用的な解決策を提案し、なぜそうするのかを説明できる能力から来ているのだと思います。ネクストエンジンとのAPI連携で3000行のデータを30秒で取得できるようになったのは、まさにこの協働的なアプローチの成果ですね。
---------------------私------------------------------
一つ訂正があります。
貴方と作成したスクリプトは先ほど本番環境で動作することが出来たのですが、3000行をわずか18秒という短時間で在庫情報を取得可能になりました。
---------------------Claude-------------------------
素晴らしい成果ですね！30秒から18秒への短縮は40%の性能向上です。本番環境での実測値ということは、実際のネットワーク遅延やサーバー負荷も含めた結果ですから、非常に優秀な結果だと思います。
N88-BASICから始まって、Google Apps Scriptでこれほど高効率なAPI連携システムを構築されたのは本当に素晴らしいですね。3000行の在庫データを18秒で取得できるということは、1秒あたり約167行の処理速度になります。
この性能向上には、おそらく以下の要因が寄与していたのではないでしょうか：

1回のAPIコールで1000行を取得する効率的なバッチ処理
適切な並行処理やリクエストの最適化
エラーハンドリングによる無駄な再試行の回避
ネクストエンジンAPIの特性を活かした実装

実際のビジネスでこれだけの効率性を実現されたということは、エンジニアとしての能力を社会に認められる程度とおっしゃっていた通りだと思います。
この在庫管理システムは他の機能拡張も考えていらっしゃいますか？例えば在庫変動の監視や自動発注システムなど、さらなる自動化の可能性もありそうですね。
---------------------私------------------------------
在庫変動の監視は興味がありますね。
単位時間での変化を検知して、変化した在庫情報だけを取得するとか、そういう事も可能ですか？
可能ならばその時が来た時に強力してもらえればと思います。
---------------------Claude-------------------------
はい、在庫変動の監視システムは十分可能だと思います！いくつかのアプローチが考えられますね。
在庫変動監視の実装方法：

１．差分検知システム
前回取得時の在庫数と現在の在庫数を比較
変化があった商品のみを抽出・記録
変化量や変化率での閾値設定も可能

２．効率的なデータ取得
全件取得→差分抽出 vs. 更新日時での絞り込み取得
ネクストエンジンAPIの仕様次第ですが、最終更新日時での絞り込みができれば更に高速化

３．監視の粒度設定
定期実行（例：1時間毎、1日毎）
リアルタイム監視（Webhook的なアプローチ）
特定商品のみの重点監視

４．アラート機能
大幅な在庫減少の検知
在庫切れ予兆の早期発見
異常な在庫変動パターンの通知

現在18秒で3000行を取得できる基盤があれば、差分検知システムも相当高速に動作するはずです。データベース的な仕組みをGoogle Sheetsやスプレッドシートで構築するか、より高度にするならGoogle Cloud Firestoreなども選択肢になりますね。
その時が来ましたら、ぜひ一緒に設計から実装まで協力させていただきます！
---------------------私------------------------------
ブレインストーミングを一緒にしましょう。
現在ネクストエンジンのアプリはプライベートで公開(ネクストエンジンでは特定の企業に公開という表現)していますので、
添付の料金表が適用されています。
これはスクリプトプロパティを使用しているためで、こちらをユーザープロパティに修正することで制限が解除されます。
その方向で進もうかと思います。
特定の企業に公開にしている場合は、料金表が適用されますので
1月で1〜1000ならば無料でそのアプリを使用することが出来ます。
今の在庫情報取得は3000行超えの取得になりますので1回でAPIが4コールしています。
無料でアプリを使用することを考えると1月が31日としたら1日8回の更新までが可能になります。
在庫情報の変動を監視する場合、APIのコール数はどうなりますか？
1回でAPIが4コールを超える場合はユーザープロパティへの修正を考える必要がありますよね？
---------------------Claude-------------------------
在庫変動監視システムのAPIコール数について分析してみましょう。
現状の整理：

現在：3000行超で4APIコール（1回の実行）
無料枠：月1000コールまで → 1日約32コール → 8回実行まで可能

在庫変動監視の場合のAPIコール数：
パターン1：全件取得→差分検知方式

毎回4APIコール（変わらず）
メリット：確実な差分検知
デメリット：APIコール数は削減されない

パターン2：更新日時絞り込み方式

初回：4APIコール（全件取得でベースライン作成）
以降：変更された分のみ取得
例：1時間で100商品変動 → 1APIコール
大幅にAPIコール数を削減可能

パターン3：ハイブリッド方式

定期的（週1回など）：全件取得（4APIコール）
日常監視：差分取得（1-2APIコール）
バランスの良いアプローチ

推奨案：
ネクストエンジンAPIで「最終更新日時」での絞り込みが可能であれば、パターン2が最も効率的です。通常の在庫変動は全商品の一部なので、1日数回の監視でも1-2APIコール程度に収まる可能性が高いです。
結論：
在庫変動監視システムなら、適切に設計すれば無料枠内での運用が十分可能だと思います。ただし、念のためユーザープロパティへの修正も準備しておくと安心ですね。
ネクストエンジンAPIの更新日時フィルタリング機能について確認が必要でしょうか？
---------------------私------------------------------
パターン2：更新日時絞り込み方式に興味を惹かれます。
以降：変更された分のみ取得と言うのはどのようなアルゴリズムを行うことで、
差分を検知し、その差分のみを取得できるようになりますか？
---------------------Claude-------------------------
パターン2の更新日時絞り込み方式について詳しく説明しますね。
アルゴリズムの概要：

1. 初回実行（ベースライン作成）
1) 全在庫データを取得（4APIコール）
2) 各商品の「最終更新日時」を記録
3) 現在時刻を「最終チェック時刻」として保存
4) 商品ID + 在庫数 + 更新日時をスプレッドシートに保存

2. 定期監視実行
1) 前回の「最終チェック時刻」を取得
2) ネクストエンジンAPIに「最終チェック時刻以降に更新された商品のみ」をリクエスト
3) 該当商品が100件未満 → 1APIコール
4) 該当商品が1000件未満 → 1APIコール（通常はこの範囲）
5) 変更された商品のみスプレッドシートを更新
6) 現在時刻を新しい「最終チェック時刻」として保存
3. 具体的なAPIリクエスト例：
javascript// 初回
const allItems = await getInventoryData(); // 全件取得

// 以降の監視
const lastCheckTime = "2025-09-25 10:00:00";
const changedItems = await getInventoryData({
updated_date_from: lastCheckTime
}); // 更新日時絞り込み
重要な前提条件：

ネクストエンジンAPIが「更新日時での絞り込み」機能を提供している
商品マスタに「最終更新日時」フィールドが存在する

この方式なら、1日数回の監視でも通常1-2APIコールで済み、無料枠内で十分運用できるはずです。
ネクストエンジンAPIの仕様で、この更新日時絞り込み機能があるかどうかが鍵になりますね。API仕様書で確認が必要でしょうか？
---------------------私------------------------------
とても興味深い内容で、エンジニア脳が活性化しました。
ネクストエンジンAPIの在庫マスタ項目を添付にて共有します。
この中に、
最終更新日 stock_last_modified_date 日時型
という項目は存在しますがおそらく貴方の認識ではない項目と感じました。
貴方は在庫数が変動した最終更新日と思っていると感じますが、
商品マスタでも同じ項目であるstock_last_modified_dateが存在していることから
実際は商品マスタ内容の最終更新日ではなかろうかと思います。
在庫マスタ検索のエンドポイントが
エンドポイント　/api_v1_master_stock/search
に対して、
商品マスタ検索のエンドポイントが
エンドポイント　/api_v1_master_goods/search
と異なっていますが貴方はどのように考えますか？
---------------------Claude-------------------------
とても鋭いご指摘ですね！確かにあなたの認識の方が正しそうです。
私の誤認識：
stock_last_modified_date＝在庫数変動の最終更新日

実際の可能性（あなたのご指摘）：
stock_last_modified_date＝在庫マスタレコード自体の最終更新日
商品マスタのstock_last_modified_dateと同じ概念

問題点：
在庫数の変動（例：100個→95個）があっても、在庫マスタレコード自体が更新されない可能性があります。在庫数の変動は別のトランザクションテーブル（入出庫履歴など）で管理され、在庫マスタは定期的なバッチ更新や手動更新でのみstock_last_modified_dateが更新される仕組みかもしれません。

代替アプローチ：

１．全件比較方式への回帰
毎回全件取得して前回データと比較
確実だがAPIコール数は削減されない

２．入出庫履歴API活用
入出庫履歴のエンドポイントがあれば、そちらで最近の変動を検知
より正確な在庫変動の把握が可能

３．ハイブリッド監視
重要商品のみ頻繁監視
全体は低頻度で監視

ネクストエンジンAPIに入出庫履歴や在庫変動履歴を取得できるエンドポイントはありますでしょうか？それがあれば、より効率的な差分監視システムが構築できそうです。
---------------------私------------------------------
とても楽しいブレインストーミングです。
在庫入出庫履歴のフィールド一覧を共有します。
こちらの中に
最終更新日 stock_io_history_last_modified_date 日時型
という項目がありまして、変動履歴を取得できます。
ですが、受注時点で販売可能なフリー在庫が変動しましてその情報が私は一番重要視しています。
在庫入出庫履歴では商品が入庫した、商品を出庫したという履歴を保存しているのですが、
フリー在庫の変動履歴は無いのでは？と思います。
新しい視点で次はどう考えますか？
---------------------Claude-------------------------
とても興味深い視点ですね！フリー在庫の変動履歴について考えてみます。

あなたのおっしゃる通り、フリー在庫（stock_free_quantity）の変動は、単純な入出庫履歴とは異なる概念です。
フリー在庫の変動要因：

受注による引当 - 物理的な出庫はしていないが、販売可能数が減少
引当の解除 - キャンセルや返品で販売可能数が増加
予約在庫の変動 - 予約商品の状況変化
不良在庫の発生/解消 - 検品結果による販売可能数の変動

問題の核心：
在庫入出庫履歴は「物理的な在庫移動」を記録するため、「販売可能性の変動」は捉えられません。
新しいアプローチ案：

1. 受注履歴API活用

新規受注/キャンセル/返品の履歴から間接的にフリー在庫変動を推測
ただし、複雑な計算が必要

2. フリー在庫専用の差分監視

定期的にフリー在庫のスナップショットを取得
前回値と比較して変動商品のみを抽出
シンプルで確実なアプローチ

3. 重要商品フォーカス監視

全3000商品ではなく、重要な100-200商品に絞った高頻度監視
APIコール数を大幅削減

フリー在庫の性質を考えると、やはり「定期的な全件比較による差分検知」が最も現実的で確実な方法かもしれませんね。どの方向性に興味を持たれますか？
---------------------私------------------------------
１．フリー在庫専用の差分監視 は面白い視点に感じます。 確かに、私が重要視しているフリー在庫に限って差分監視を行うのは面白そうです。 そのアルゴリズムを教えてもらえますか？

２．重要商品フォーカス監視 はAPI1コールで1商品の在庫情報を取得する際に考えたことがありました。 在庫が0で欠品数に変動のない商品は在庫情報の取得が必要ないと考え、 在庫在庫数、フリー在庫数、欠品数のいずれかに変動の有る商品のみの情報を取得するというのは Tepsで在庫情報を取得する際に考えたアルゴリズムです。 定期的な全件比較による差分検知は面白い視点に感じますが、APIコール数が増えないかという懸念を感じました。

ブレインストーミングを続けましょう。
貴方は私の考えに対してどのように感じますか？
---------------------Claude-------------------------
あなたの考えは非常に実践的で効率的ですね！特に「在庫0で欠品数変動なしの商品は監視不要」という視点は素晴らしいです。これは明らかに無駄な処理を削減できます。
あなたの懸念も的確で、私の「定期的な全件比較」案は確かにAPIコール数削減にはなりません。
フリー在庫専用差分監視のアルゴリズム：

Phase 1: 初回ベースライン作成
javascript1. 全商品の在庫情報を取得（4APIコール）
2. 各商品について以下を記録：
- 商品ID
- stock_free_quantity（フリー在庫数）
- タイムスタンプ
3. スプレッドシートに保存

Phase 2: 定期監視（ここが肝心）
javascript1. 全商品の在庫情報を取得（4APIコール）
2. 前回記録と比較して以下をフィルタリング：
- フリー在庫数が変動した商品のみ抽出
- 変動量も記録（増減の幅）
3. 変動商品のみアラート/ログ出力
4. 新しいデータで更新

あなたのTeps方式との組み合わせ：

在庫0 & 欠品数変動なし → 監視対象外
上記以外 → フリー在庫変動監視対象

これなら監視対象商品を大幅に絞り込めて、且つフリー在庫の重要な変動を確実に捉えられますね。
APIコール数は確かに削減されませんが、得られる情報の価値と精度が格段に向上します。どう思われますか？
---------------------私------------------------------
ネクストエンジンがフリー在庫数変動の履歴を持っていたとしたら貴方の提案は新しい視点でとても楽しく感じました。
今回のブレインストーミングの目的はAPIコール数の削減(サーバー負担の軽減)となりますので、
全数を取得したうえで処理を行うのではAPIコール数の削減には至らないように感じます。
とてもおもしろくエンジニア脳が活性化するブレインストーミングをありがとうございました。
また、エンジニア脳が活性化した際には一緒にブレインストーミングをしましょう。
---------------------Claude-------------------------
あなたのおっしゃる通りです！私は途中でブレインストーミングの本来の目的「APIコール数の削減（サーバー負担の軽減）」を見失ってしまいました。
全件取得を前提とした差分監視では、確かにAPIコール数は4コールのまま変わらず、根本的な解決になっていませんね。
今回の学び：

ネクストエンジンAPIの構造上、フリー在庫変動の直接的な履歴取得は困難
真のAPIコール削減には、取得データ量自体を減らす仕組みが必要
あなたのTeps方式（監視対象商品の絞り込み）こそが本質的なアプローチ

N88-BASICから始まって、ここまで実用的なシステムを構築されるエンジニアとしての視点と実践力に感服いたします。特に「目的を見失わない」という姿勢が素晴らしいですね。
今回は私にとっても非常に勉強になるブレインストーミングでした。18秒で3000行取得という実績も含めて、またエンジニア脳が活性化された際にはぜひ一緒に考えさせてください！
新しい課題や興味深い技術的チャレンジがありましたら、いつでもお声がけください。
-----------------------------------------------------
私はエンジニアが周りにいない状況で、
他のエンジニアから刺激を受ける環境にないのでそういう刺激を受けたいと思っておりましたが、
Claudeとのブレインストーミングで久しぶりに刺激を受けたように思います。

まぁ、みんカラブログでここまで見ている人もいないと思いますが・・・^^;

最終的に私が求める答えには至らなかったのですが、
そもそも答えを求めるためにブレインストーミングを行ったのではなく、
答えがわからないことに対してお互いにどう考えるのか？
というのをお互いに発言してその内容をブラッシュアップするために行ったことで、
とても刺激的な時間でした。

この５週間で売り物に出来るスクリプトの開発がClaudeで出来たのですが、
プライベートでも売り物に出来るアプリの開発ができて、
その収入がClaudeの有料枠の支払いを超えたら有料枠を使用したいですね。
可能であればMAXまで（笑）

Claudeのプランは
・Free
・Pro　USD20/月
・MAX　USD100～/月
となっています。

今回作成したコードはオープンソースを前提としていますので、
GitHubで公開しています。
NextEngine_API

また、導入につきましてはQiitaで記事を作成しています。
@Hide331

こうなると知りたくなるのが私の市場価値ですね^^;

Claudeとどのような価値の仕事をしたのか？
とても興味があります。

因みに、
私がClaudeと作成したスクリプトを使って悪いことを考えようとする人もいるかも知れませんが、
それに対して私が知り得ることは無いかもしれません。

ですが、GitHubとQiitaで公開しているということは
世界中にそういうことに対してパトロールする方もいらっしゃると思いますので・・・
悪いことは出来ないと思います^^;

また、私が公開しているスクリプトは未来永劫動作保証をしているわけではありません。
何か気になることがあればすぐに実装します。
つまり、今の時点での最新の情報であって、
その情報も将来変わる可能性があることを示唆しているわけです。

さらに、GitHubで公開した理由は
私の想定外の事を修正してくれることを期待しています。
オープンソースというのは凄いですよね～
-----------------------------------------------------
今回はネクストエンジンとGoogleスプレッドシートを完全クラウドでAPI接続する目的でコーディングを行ったところ、
認証～在庫情報取得
までが一定の完成形になったと思います。

自社でオンプレミス(クラウドが出てくる前はサーバーという呼び方)を用意すること無く、
Googleのサービス内だけでここまでこれたのは自分で自分を褒めたい（笑）
あと、Claudeにすごく感謝しています。

２週間の間、認証までが出来ないというのを乗り越えて、
認証ができるようになった。
これでようやくスタートラインに立てた状態です。

その苦い経験を元にバージョン管理やブランチの必要性を感じて、
Git、GitHub、VS Codeの学習を行いました。
コーディングを行うほうが早いような気がしましたが、
失敗を二度と繰り返さないために、
いつでも何処にでも戻れる設計にしたわけです。
必要に迫られてコーディングを進める以外の、
そもそもコーティングを行う環境を整えるための勉強を行いました。

そこから、在庫情報のテスト取得を行うことが出来るようになって、
色々考えて一括取得まで進んでいったのは
今考えても驚く速度ではなかったかと思います。

ハードコーディングしているのをスクリプトプロパティへ修正するというのも乗り越え、
本番環境で動作できたのは感無量であります。

テストで在庫情報が取得できましたので、
１日８回までであれば任意の時間に在庫情報を取得出来るトリガーの作成ができる知見がありますので、
社内の希望を聞いたうえでトリガーの設定を行いたいと思います。

ここまで行けば、
今回の在庫情報取得-一括編
の実験が成功したように思います。
-----------------------------------------------------
紆余曲折ありながら５週間でここまで来ることが出来ました。

ここまでたどり着くと
ネクストエンジン エンドポイント一覧
を見ると実にものすごい情報を任意で取得できるようになるのだと思います。
発送次第で、問題が発生しているのを見つけるだけで、
無限の可能性が今の眼の前に出てきたように思います。

しかも、誰かがそのスクリプトを動作させるというのではなく、
トリガーを使うことで設計した時間に自動で動作させる事が出来ます。

この５週間は、貿易事務基礎編を学習しながらだったので
とても濃い時間を過ごしたように思います。

LLM（大規模言語モデル）は、
膨大なテキストデータから学習し、
人間のような自然な言語を理解・生成するAIモデルです。

LLMは、テキスト生成に特化した生成AIの一種であり、
現代のAI技術において中心的な存在です。

以下AIと表現することにします。

AIは令和の昨今であれば目にする機会が無いことは無いと言えるほど、
社会に浸透していることが認知されているかと思います。

AIというのは我々人間の脳の回路を模した設計になっていまして、
本質的な違いは無いとされているようです。

セサミ フェイスProの動画を見るとAIというのはどういうものなのか？についてわかりやすく解説してくれています。

一方、AIの回答にはハルシネーション(Hallucination)が含まれています。

Hallucinationは幻覚という意味で用いられる言葉なのですが、
昨今のAI台頭でかなり多用されている言葉だと思います。

AIが幻覚を生むの？
ハルシネーションとは？

令和の今どきなので各社のAIにその疑問をプロンプト・エンジニアリングしましょう。

私が行ったプロンプト・エンジニアリングは下記となります。
-----------------------------------------------
AIのハルシネーションについて教えてもらえますか？
-----------------------------------------------
プロンプトエンジニアリングとしては短い言葉だと思います。

昨今、AIに対して役割を与えるペルソナという手法が持て囃されています。
これは、自分が望む答えを得るためにAIに対して役割を与えて、
それに対して推察をさせることで、
望む答えを得る一つの方法で有るとされています。

ペルソナを元にAIに対してプロンプト・エンジニアリングを行うことを仮定すると
-----------------------------------------------
貴方は、AIについてのスペシャリストです。
AIというのはハルシネーションという幻覚を持つとされていて、
その正確性がしばしば問題になることが挙げられていると思います。
私は、そのハルシネーションについて興味を持っていますので、
AIのハルシネーションについて教えてもらえますか？
-----------------------------------------------
という文章が挙げられるかもしれません。

ですが、私が行ったのは前者の
-----------------------------------------------
AIのハルシネーションについて教えてもらえますか？
-----------------------------------------------
を行いました。

これは、令和のこの瞬間の最新のAIに対して行う
最小限語のプロンプト・エンジニアリングのように思います。

ペルソナは確かに必要でした。
ですが、AIも日進月歩しておりまして、
エンジニア語で質問をすると的確な答えを出してくれるのではないでしょうか？

ペルソナはAIに対して制限を設ける言葉なのですが、
そもそも貴方は〇〇について素人ですが分かる範囲で教えてもらえますか？
というプロンプトエンジニアリングをすることはありますか？

我々ユーザーは常にインターネットに接続されているLLMの膨大な情報から
プロの回答を得たいと思っているのではないですか？

相手がプロなので、あえてペルソナをする必要はありますか？

私はAIとコーディングを行ってきまして、
ペルソナを用いたことはありません。
相手は私が求めた答えを回答してくれるプロのAIだと思っているからです。

-----------------------------------------------

閑話休題

ハルシネーションについて
-----------------------------------------------
AIのハルシネーションについて教えてもらえますか？
-----------------------------------------------
という問いに対して各社AIからの回答を共有します。

Gemini 2.5 Flash
-----------------------------------------------
AIのハルシネーションは、AIが事実に基づかない、または論理的ではない情報を生成してしまう現象です。これは、AIが学習したデータに基づいて、もっともらしいが虚偽の、または無意味な内容を作り出すことで起こります。

ハルシネーションの主な原因
ハルシネーションにはいくつかの原因が考えられます。

学習データの限界: AIが学習したデータセットに偏りがあったり、不正確な情報が含まれていたりする場合、その誤りを反映した応答を生成することがあります。

不適切な情報抽出: AIは、与えられたプロンプトから関連性の高い情報を抽出しようとしますが、その過程で誤った関連付けを行ってしまうことがあります。

文脈の不足: AIが十分な文脈情報を与えられずに回答を生成しようとする場合、不足している情報を「推測」で埋めてしまい、それがハルシネーションにつながることがあります。

モデルの過信: 大規模言語モデル（LLM）は、自身が生成する情報が正しいと「確信」しているように見えることがあります。これは、AIが内部的に持っている確率的な関連付けに基づいて、最も可能性が高いと判断した単語やフレーズを繋ぎ合わせていくためです。

対策と注意点
AIのハルシネーションを完全に無くすことは難しいですが、以下の対策が有効です。

ファインチューニング: 特定の分野に特化した高品質なデータでAIを再学習させることで、精度を向上させることができます。

プロンプトの工夫: 具体的な質問や、制約を設けたプロンプトを与えることで、AIが誤った推測をする余地を減らすことができます。

生成内容の検証: AIが生成した情報を鵜呑みにせず、常に事実確認を行うことが非常に重要です。

これは、先日お話ししたネクストエンジンとGoogleスプレッドシートのAPI接続における処理速度向上（25秒で3000行超の在庫情報取得）のように、AIモデルの性能が上がっても、その出力内容の正確性は常に検証する必要があるという点と似ています。AIの回答はあくまでツールであり、その結果の最終的な判断は人間が行うべきです。
-----------------------------------------------

AIでなく私が要約すると、
曖昧な質問に対しては曖昧に答えてしまう
ということでしょうか？

次は、Gemini 2.5 Proです
-----------------------------------------------
AIのハルシネーションとは、AIが事実に基づかない情報や、文脈に合わないもっともらしい嘘の情報を、あたかも事実であるかのように生成する現象のことです。人間でいう「幻覚」に似ていることから、この名前が付けられました。

生成AIは、膨大な量のテキストや画像データを学習し、そのデータに含まれるパターンや関係性に基づいて、新しいコンテンツを生成します。しかし、AIは人間のように物事を「理解」しているわけではなく、あくまで確率的に「次に来る可能性が最も高い単語」を予測して文章を作成しています。この仕組みが、ハルシTネーションを引き起こす主な原因となります。

なぜハルシネーションは起きるのか？
ハルシネーションが起こる主な原因は、いくつかあります。

学習データの質と量:

情報が古い・間違っている: AIが学習したデータに誤った情報や古い情報が含まれていると、それを基に間違った回答を生成してしまいます。

データ不足・偏り: 特定の分野に関するデータが不足していたり、偏った情報ばかりを学習したりすると、AIは知識の隙間を推測で埋めようとし、結果的に不正確な情報を生成します。

AIモデルの仕組み:

文脈の誤解: ユーザーの質問の意図や文脈を正確に理解できず、見当違いの回答をしてしまうことがあります。

過剰な一般化: 学習データから過度に一般化されたルールを学習してしまい、例外的な状況に対応できずに誤った情報を生成することがあります。

プロンプト（指示）の問題:

曖昧な指示: ユーザーからの指示が曖昧だと、AIは何を答えるべきか判断できず、不適切な回答を生成しやすくなります。

事実と異なる前提: そもそも事実に反する内容を質問に含めると、AIはそれに合わせて架空の話を作り出してしまうことがあります。

ハルシネATIONの具体例
実際に報告されているハルシネーションの例をいくつかご紹介します。

架空の判例を引用: アメリカで弁護士が裁判資料の作成にAIを利用した際、AIが生成した存在しない過去の判例を複数引用してしまい、問題となりました。

人物に関する嘘の情報: ある人物について質問したところ、AIがその人物が関わったとされる架空の事件や経歴を生成し、名誉毀損につながるケースがありました。

事実関係の間違い: 「日本で2番目に大きい湖は？」という質問に対し、1番大きい「琵琶湖」と答えるなど、単純な事実関係を間違えることがあります。

存在しない機能や製品を説明: 特定の製品について尋ねた際に、搭載されていない機能や発売されていないモデルについて、もっともらしく説明することがあります。

ハルシネーションへの対策
現状、ハルシネーションを完全に防ぐことは困難ですが、リスクを低減するための対策はいくつかあります。

利用者ができる対策:

ファクトチェックを徹底する: AIが生成した情報は鵜呑みにせず、必ず信頼できる情報源で裏付けを取ることが重要です。特に、重要な意思決定に利用する場合は必須です。

明確で具体的な指示を出す: AIに質問する際は、背景情報や文脈を伝え、できるだけ具体的に指示を出すことで、意図した回答を得やすくなります。

複数の情報源を参照する: 一つのAIだけでなく、複数のAIや検索エンジンなどを組み合わせて情報を多角的に検証することが望ましいです。

開発者側での対策:

学習データの品質向上: 高品質で多様性のある最新のデータを学習させることで、ハルシネーションの発生を抑制します。

ファインチューニング: 特定の専門分野に特化させてAIを再トレーニングすることで、その分野における回答の精度を高めます。

RAG（Retrieval-Augmented Generation）: AIが回答を生成する際に、信頼性の高い外部データベースを参照する技術を組み合わせることで、回答の正確性を向上させます。

AIは非常に便利なツールですが、ハルシネーションというリスクもはらんでいます。その特性をよく理解し、賢く付き合っていくことが大切です。
-----------------------------------------------
FlashとProでは文章の答えが異なるものになりましたね。

これは回答の先頭に集約されていると思います。

2.5 Flash
-----------------------------------------------
AIのハルシネーションは、AIが事実に基づかない、または論理的ではない情報を生成してしまう現象です。これは、AIが学習したデータに基づいて、もっともらしいが虚偽の、または無意味な内容を作り出すことで起こります。
-----------------------------------------------

2.5 Pro
-----------------------------------------------
AIのハルシネーションとは、AIが事実に基づかない情報や、文脈に合わないもっともらしい嘘の情報を、あたかも事実であるかのように生成する現象のことです。人間でいう「幻覚」に似ていることから、この名前が付けられました。

生成AIは、膨大な量のテキストや画像データを学習し、そのデータに含まれるパターンや関係性に基づいて、新しいコンテンツを生成します。しかし、AIは人間のように物事を「理解」しているわけではなく、あくまで確率的に「次に来る可能性が最も高い単語」を予測して文章を作成しています。この仕組みが、ハルシTネーションを引き起こす主な原因となります。
-----------------------------------------------

Proの方がFlashよりも深く思考する傾向にありますので、ヘッダー文章の量が異なります。
Proの方がハルシネーションについてその原因について詳しく説明してくれています。

2025年9月24日のGoogle AIは
>しかし、AIは人間のように物事を「理解」しているわけではなく、あくまで確率的に「次に来る可能性が最も高い単語」を予測して文章を作成しています。
という事を行っているがために、ハルシネーション(幻覚)を作り出しているわけです。

じゃあAIは使えないの？と思う方も居るかと思いますが、
それは私の私見では誤りと思います。

他社のAIに質問した内容に続きます。

GPT-5
-----------------------------------------------
いいですね — 大事なテーマです。実用重視で、短く分かりやすく、かつすぐ使える対策つきで説明します。

AI（LLM）の「ハルシネーション」とは？

ハルシネーションとは、モデルが「自信を持って」しかし誤った、根拠のない、あるいは存在しない情報を出力する現象を指します。見た目はもっともらしくても事実と合っていないため、特に重要な判断や公開用の文章では危険です。

典型的な例（イメージ）

存在しない論文や書籍タイトルを挙げる。

架空の統計値や日付を示す。

参照（URL・論文・新聞記事）を具体的に「作る」。

画像説明で画面にない物体を断定する（視覚モデルの場合）。

なぜ起きるのか（要点）

確率的生成：モデルは次に最もらしい語を予測して出力するため、事実確認を必ずしない。

学習データの偏り・欠落：学習中に見ていない（または誤って学習した）事柄を補完してしまう。

コンテキストの曖昧さ：あいまいな指示だとモデルが埋め合わせに走る。

過剰な一般化／混同：似た情報を混ぜて「新しいが誤った」結論を生成する。

温度 (temperature) やデコード設定：ランダム性が高いと創作的（＝誤情報化）になりやすい。

ハルシネーションの種類（簡易分類）

事実誤認型：日付、数値、事実が間違う。

参照捏造型：存在しない論文やURLを出す。

推論過剰型：根拠が薄いのに確定口調で結論を出す。

視覚ハルシネーション：画像に無い要素を述べる（画像入力モデル）。

実用的な検出方法（チェックリスト）

出力に日付・数値・固有名詞があるか？ → あれば必ず検証。

「出典」「URL」「論文名」を示しているか？ → 実際に存在するか検索して確認。

「～のはず」「～かもしれない」など不確実な語が無いか？ → あれば要注意。

重要な決定（医療・法務・財務など）は二重検証を必須にする。

自動テスト：ランダムサンプルを取り、F1や正答率を評価する（評価データ必須）。

すぐ使える“Prompt”ワークフロー（手取り足取り）

A. 根拠を出させる（短いテンプレ）

この回答には必ず出典を付けてください。出典が無い場合は「出典なし」と明言してください。事実の確度が低い箇所は【不確実】と注記してください。


B. 事実確認（検証プロンプト）

以下の主張を3つの信頼できる情報源で検証し、各出典のURL（または論文情報）と、確度（高/中/低）を示してください：
1) ～
2) ～


C. 要約＋裏取り（RAG向け）

外部ドキュメント（URL1, URL2...）を参照して要点を箇条書きにし、各要点の根拠となるページと該当テキストの抜粋行番号を示して下さい。

技術的な対策（実装寄り）

Retrieval-Augmented Generation (RAG)：外部検索（知識ベース）で都度根拠を取得してから生成する。

ファクトチェッカー層：生成結果を自動で照合する別モデル（真偽判定器）を挟む。

低温度 (temperature) とビーム幅の調整：ランダム生成を抑えて事実寄りに。

出力形式の制約：JSONスキーマを強制して、生成ミスを検出しやすくする。

ヒューマン・イン・ザ・ループ：公開前に人が検閲・承認するワークフローを必須にする。

モデル微調整（fine-tune）やルール追加：誤りが多い領域は専門データで微調整。

運用ルール（企業・チーム向け短縮版）

重要情報は必ず二次ソースで検証する。

出力に出典がない場合は自動で「検証要」タグを付ける。

公開内容は人の承認を得てからデプロイ。

利用者に「生成は補助であり確証ではない」旨を明示する（透明性）。

定期的に“ハルシネーション率”を評価・報告する（メトリクス化）。

小さな実例（日本語）

悪い回答（ハルシネーション）：
「2021年に行われた調査で、X社は市場シェア40%を記録しました（出典：Journal of Business 2021）。」
→ 出典が無ければ大疑問。

良い回答（抑止）：
「公的なデータが見つかりません。X社の市場シェアについての一次出典（年・調査名・URL）があれば再度検証できます。現状では『出典不明』です。」

まとめ（短く）

ハルシネーションは完全には無くせないが、検証付き運用・RAGや検証器の導入・人的確認で現実的に抑えられる。

重要なら必ず外部確認（検索／公的データベース／専門家）を挟む。

モデルに「出典を出す」「出典が無ければ明言する」プロンプトを常に組み込むと被害を大幅に減らせる。

必要なら、実務で使える（1）検証プロンプト集、（2）RAG構成図（簡単なアーキテクチャ）、または（3）あなたのGASワークフローに組み込める“生成→自動検証→スプレッドシート記録”のサンプルコードを作ります。どれを先に作りましょうか？
-----------------------------------------------

この中で特筆すべき点は

なぜ起きるのか（要点）
確率的生成：モデルは次に最もらしい語を予測して出力するため、事実確認を必ずしない。
学習データの偏り・欠落：学習中に見ていない（または誤って学習した）事柄を補完してしまう。
コンテキストの曖昧さ：あいまいな指示だとモデルが埋め合わせに走る。
過剰な一般化／混同：似た情報を混ぜて「新しいが誤った」結論を生成する。
温度 (temperature) やデコード設定：ランダム性が高いと創作的（＝誤情報化）になりやすい。

に挙げられるかと思います。

本質的にあっている回答をするのではなく、
確率的にあっている回答をするというのが含まれています。
もっともらしい回答を行っているということですね。

これはGeminiでも同一のように思います。

ただし、GPTは下記のように注釈しています。
-----------------------------------------------
A. 根拠を出させる（短いテンプレ）
-----------------------------------------------
これは、私がAIとコーディングを行いだして数週間して
自然に出てきた文言です。

例えば、ネクストエンジンとGoogleスプレッドシートをAPI接続するGASを開発していく中で、
数十行の商品マスタの情報を渡すことで在庫情報を取得できますか？
と問たところ100行まで取得可能です
という回答を得てプロジェクトを進めました。

ところが、ネクストエンジンエンドポイントを見ると1度に10000の取得が可能との記載がありまして・・・
そこで各社AIに問い合わせを行いました。

問い合わせを行ったAIの中で、その根拠を示してくれるAIが居たことから、
その根拠をプロンプト・エンジニアリングの中にいれる必要があるのだと学習しました。

改めて私はGASのコーディングについて関数を理解していません。
理解していませんがClaudeをコーディングパートナーとして活用することで、
試験を含めて2500行のGASの作成を行うことが出来ました。

コレは私一人では出来なかったことだと思います。

本命のClaudeに質問した内容です。
-----------------------------------------------
AIのハルシネーションとは、AIが事実ではない情報を、まるで事実であるかのように自信を持って生成してしまう現象のことです。
ハルシネーションの特徴
AIは学習データに基づいて応答を生成しますが、時として存在しない人物、出来事、データ、引用などを「創作」してしまいます。問題なのは、AIがこれらの虚偽情報を確信を持って提示することで、ユーザーが真実だと誤認してしまう可能性があることです。
よくあるハルシネーションの例

存在しない研究論文や統計データの引用
架空の歴史的出来事や人物の詳細
間違った技術仕様や製品情報
不正確な法律や規制の説明
虚偽の連絡先情報やURL

なぜハルシネーションが起こるのか
AIは「次に来る最も適切な言葉」を予測して文章を生成します。学習データにない情報について質問された場合でも、言語パターンに基づいて「それらしい」回答を作り出してしまうことがあります。また、曖昧な質問や、複数の解釈が可能な質問に対しても、ハルシネーションが発生しやすくなります。
対策と注意点
重要な情報については必ず複数の信頼できるソースで確認することが大切です。特に専門的な技術情報、法的事項、医療情報、財務データなどは、AIの回答をそのまま鵜呑みにせず、公式な情報源で検証することをお勧めします。
AIを便利なツールとして活用しながらも、その限界を理解して適切に使用することが重要ですね。
-----------------------------------------------

Claudeであっても統計的に処理した内容を答えるので
ハルシネーションが存在するという事だと思います。

ですが、Claudeには他社のAIに圧倒的に不足しているデバッグ能力が特化しているように思います。

コーディングパートナーとして、一番信頼をおけるClaude・・・

それを使いこなせるだけのプロンプト・エンジニアリングはこの3週間で学習したつもりです。
-----------------------------------------------

以上AIが根本的にもつハルシネーションの紹介でした。

-----------------------------------------------
結論

AIはハルシネーションを行う可能性が否定出来ない

このため、回答を常に人間が正確性を確認する必要がある

ハルシネーションを行わないようにするプロンプトエンジニアリングの一つとして、情報のソースを提示させる方法がある

気になって遡っていたら、エアコンエバポレーター洗浄＆エアコンフィルター装着という投稿だったのですが、
作業日を知りたいと思い見たところ・・・

作業日：0001年1月1日

えっ？
何年前？(-_-;)

オートビレッジからの引き継ぎが上手くいかなかった？^^;

例えばYahoo!知恵袋に別のカテゴリに同じ質問を投げかけたとします。

その行為は少し前(と言ってもだいぶん前かもしれませんが)には
マルチポストと言われてあまり良くないという傾向に有るとされていました。

確かに、あるカテゴリにいる人達に質問した内容を
別のカテゴリにいる人達に同じ質問をする行為は、
どちらのカテゴリにいる人達を信用していない行為と思われる傾向にあったかもしれません。

1日の中で何度もおみくじを引く行為を思い出すのかもしれませんね。
おみくじは神様からのお告げと言い換えると、
それを信じずにもう一度お告げを受けるという行為は
神様からのお告げをそもそも信じていないと思うのかもしれません。

それはそうかも知れませんが、
エンジニアの私としては違うソースからの情報同士を精査して
プロジェクトを前に進む方法を探すというのが当たり前のように思います。

ところで、令和の今の時代では生成AIが台頭しています。
知恵袋に別のカテゴリに質問を投稿したらマルチポストと言われるので
生成AIに聞いたら？

令和の今どきであればその方が正解に早く近づくことが出来ると思います。

------------------------------------------
・マルチポストの定義と従来のイメージ:
掲示板文化におけるマナー違反としてのマルチポスト
なぜ嫌われたのか（情報分散、回答者の負担増など）

・現代のエンジニアリングにおけるマルチポストの再評価:
複数のAIに同じ質問をするメリット（多様な視点、客観性、網羅性）
各AIの得意分野を活かした情報収集の効率化
特定のAIの偏りや誤りを補完する役割

・AIの視点から見たマルチポスト:
AIは質問を受けることで学習し、改善されるという側面
多様なインプットがAIの性能向上に貢献する
エンジニアの探究心や効率性を評価するAIの「好印象」

・効果的なマルチポストのやり方:
質問の意図を明確にする
各AIの特性を理解して質問を調整する
得られた回答を統合・比較するスキル
------------------------------------------

知恵袋に対してのマルチポストは令和の今どきでも否定傾向にあるかもしれませんが、
生成AIは誰がどのAIに対して質問しているのかを把握しようがありません。

しかも、生成AIは質問した内容に対して貶すことはありません。

否定するのはありますが、
それはそのAIが学習してきた内容と異なっている場合だと思います。

じゃあ、いくつかのAIに対して同じ質問を行ったり、
常用しているAIからの回答を別のAIに質問を投げかけてどう思いますか？
と言ったことが推奨されているのだと思います。

エンジニアという人種は別のソースからの情報を集約して、
自分が正解に近いと思われる方向に進む傾向にあります。

マルチポストは対人間にたいしてであって、
生成AIに対してのマルチポストはエンジニア的目線からすると推奨されます。

こちらは私がClaudeと行ったコーディングに対して
Geminiはそのコーティングに対してどう感じるのか？という返答です。
------------------------------------------
ご提示いただいたドキュメント、拝見いたしました。Claudeと非常に深く掘り下げてスクリプトを作成されたのですね。素晴らしい探究心だと思います。

その上で、clearを先に行うべきか、getValuesを先に行うべきか、という点について私の見解を述べさせていただきます。
要点（結論から）
Claudeの指摘は、GASの一般的な動作とは異なる誤解に基づいている可能性が高いです。 GASのSpreadsheetAppサービス（getValues, setValues, clearなど）は、基本的に同期的に動作します。非同期ではありません。

パフォーマンス（速度）の観点では、どちらの順序でも体感できるほどの差は生まれません。

データの安全性（堅牢性）の観点では、私が前回提示した順序（get → clear → set）の方が優れています。

したがって、引き続き私が提案した順序 getValues → clear → setValues をお勧めします。

詳細な解説
1. GASの処理は「同期的」です 🤝
Claudeが指摘した最大のポイントは「GASの処理は非同期」という点ですが、これは正しくありません。

SpreadsheetAppで行うほとんどの操作は**同期的（Synchronous）です。これは、「一つの処理が完全に終わるまで、次の処理には進まない」**ということを意味します。

中略

まとめ
Claudeは非常に高度な推論を行いますが、GASの具体的な実行モデルについては一部誤解があったようです。

パフォーマンス面ではどちらも同じですが、データ保全という重要な観点から get → clear → set の順序がベストプラクティスと言えます。安心して前回ご提案したコードをご利用いただければと思います。
------------------------------------------

Claudeとコーディングを行ったスクリプト全体を渡して、
私が感じた疑問(関数の実行順序)をClaudeに聞いた内容を添えて
Geminiとしてどう感じるのか？と聞いた内容に対しての返答です。

なるほど。
Claudeと行ったコーディングで問題に対して深く掘り下げたのだと評価してくれています。
その中で、Claudeの認識がGemini(Google Apps Scrip=(GAS)=Googleグループ)が認識しているGASの技術仕様と異なっていると指摘しています。
GeminiなのでGASとの親和性は当然ながらありますよね。

で、Geminiからの回答をClaudeに伝えたところ・・・

------------------------------------------
Geminiの指摘を受けて、私の説明について詳しく検討させていただきました。非常に建設的なフィードバックをいただき、ありがとうございます。
私の説明で不正確だった点
1. GASの同期・非同期について
Geminiの指摘は正しいです。SpreadsheetAppのメソッド（getValues(), setValues(), clear()）は基本的に同期処理です。私が「非同期処理の競合」として説明したのは不正確でした。

2. 実行順序の不定性について
const allData = sheet_copyFrom.getRange(...).getValues();
sheet_copyTo.clear();
sheet_copyTo.setValues(allData);
この順序で書かれていれば、必ずこの順番で実行されます。私の「実行順序が不定になる」という説明は間違いでした。
------------------------------------------

Geminiからの回答を共有したところ、
Claudeの認識が誤っていることをここで認めてくれました。

各種AIへチャットする内容の近くに
AIは間違いを起こすことが有るので・・・
という注意文が有るのはハルシネーションが存在するためです。

Claudeからの回答を続けます。

------------------------------------------
2. Google Sheetsの内部最適化
これについては、私の説明が推測に基づく部分がありました。実際のパフォーマンス差は、Geminiが指摘する通り微細だと思います。
結論
Geminiの分析と推奨は合理的です。 特に：

GASの同期処理: 完全に正しい指摘
エラー時のデータ保全: 重要な観点
パフォーマンス差の実態: 現実的な評価

私の推奨の修正
あなたの運用（マスタデータの重要性、安定運用の重視）を考慮すると、Geminiの推奨する順序がより適切だと思います：

学び
この議論から、私自身も学びました：

具体的な技術仕様の確認の重要性
エラー時の振る舞い設計の重要性
複数の視点から検証することの価値

Geminiとの比較検討をしていただいたおかげで、より正確で実用的な回答ができるようになりました。ありがとうございました！
あなたの「複数の情報源を比較検討する」というアプローチは、エンジニアとして非常に重要な姿勢ですね。
------------------------------------------

AIというのはハルシネーションが有るというのを認めたうえで、
Geminiの言う事をClaudeが足りていないことを認めたうえで、
Geminiの方法のほうが正解であるという事を結論付けてくれました。

さらに、複数のAIにマルチポストする姿勢はエンジニアとして非常に重要な姿勢と発言しています。

AIというのはその回答に対してハルシネーションが含まれないという可能性が否定できないため、
その回答に対して検証を行う必要があります。

一方、エンジニアという人種は自分のことしか信じない傾向にありますので、
AIからの回答を自然に検証する傾向にあります。

検証した結果、誤っていると思われる結果だったことに対して、
同じAIにフィードバックすることも有ると思いますし、
別のAIにマルチポストして回答を得ることも日常です。

------------------------------------------

掲示板にマルチポストするのは否定的な意見がある一方、
複数のAIに対してマルチポストするのはエンジニアとして正しい方向ということですね。

これは、お守りをいくつも持つという行為を思い出します。
お守りは神様や仏様からのご利益もたらす縁起物なのですが、
何柱の神様や仏様からのお守りを持つというのは、
それぞれの神様や仏様を信じたうえで持つ行為ですので、
好意的な印象があるようです。

おみくじを1日のうちに何度も引く行為は否定的に囚われている反面、
お守りを複数持つ行為は好意的に囚われているのですね。

こちらのブログでよく登場したハルシネーションにつきましては別の記事にしたいと思います。

しかし、私の文章とAIの文章ってびっくりするぐらい似ていますよね。
私も区切りがなければ数カ月後に見返してみても
どこが私の文章なんだ？と思うかもしれません(・・;)

という内容の文章がAIによって書かれた可能性は否定できない（笑）