• 車種別
  • パーツ
  • 整備手帳
  • ブログ
  • みんカラ+

ヒデノリのブログ一覧

2025年10月10日 イイね!

私が考える世界最高コーディングパートナーであるClaude

私が考える世界最高コーディングパートナーであるClaudeClaudeですがクロードと日本語では表現されることがとても多いと思います。
私はクローデェと思っていますがそんな事はどうでもいい事です。

8月17日に何年来の宿題を突然解決しなければ!という使命感が沸き起こって
AIをコーディングパートナーにしてバイブコーディングを行って参りました。

目的は
ネクストエンジン(OMS)とGoogleスプレッドシートをAPI接続するGASの開発
です。

今まで、TepsやYoomというアプリだけでなく、
SFTPサーバーを立ち上げてCSV連携を行っていましたが、
カスタムデータのスケジュールの限界、
ダウンロードできるCSVの限界を感じて、
API接続しなければならないという何年来かの宿題を行いたい欲求が突然沸き起こってきました。

まぁそんな事もこのブログ内容から外れているのでどうでもいいことですが・・・

私は2025/9/1にClaudeに出会ったことから、
バイブコーディングを行うことで、
コーディング能力が飛躍的に高まりました。

言語はフルクラウドを前提にしてGoogle Apps Scriptを前提にしたことから
Qiitaで公開している手順に従って作業することで、
私と同じ事が実行できます。

初回は在庫情報の取得です。
3000行超えの在庫情報を30秒前後で取得できるスクリプトを
Claudeをコーディングパートナーとして選んだことで
一からコーディングを学ぶより速い速度で開発が出来たように思います。
開発を始めてからネクストエンジンのアプリ承認を得るまで5週間・・・
コードを一から勉強すること無く・・・
バイブコーディングを行い始めてから・・・
2500行のスクリプトを成果として得られたのは
プロンプトエンジニアリングを行えた
という事に尽きると思います。

初回の中にはGit、GitHub、Visual Studio Codeの学習も含み、
色々コーディングパートナーを変えてきたという経緯を含んでいます。

その中で、9月1日にパートナーに選んだClaudeで開発が一気に進みました。

2回目は受注明細情報の取得です。
想定取得行数は1000~3000となっておりまして、
本日を含めて未来3日分の明細を取得するのですが、
5週間の経験を活かしてClaudeでプロジェクトを初めて作成することにしました。

プロジェクトを作成することでおそらくその中のチャット内容が共有され、
プロジェクトの目的を説明文として入力することも出来ました。

プロジェクトの冒頭に細かくプロンプトエンジニアリングを行うことで、
計画を立案してもらい、
それに従ってステップ・バイ・ステップで進むことが出来ました。

無料枠で使用しているのでその上限に接触する事もいくつかありますが、
2回目は1.5日でテスト環境での開発を終了させることが出来、
アプリの申請まで進むことが出来ました。

5週間かかっていた作業が・・・
全く同じ作業ではないとは言え1.5日に短縮とは・・・

AIと言ってもどうせ・・・
という言葉が聞こえてきますが私はClaude無しの生活は考えられません。

当然、毎日より良いプロンプトエンジニアリングを行うにはどうしたら良いのか?を考えておりますが、
5週間が1.5日に短縮とは想像を絶するパフォーマンスを発揮してくれていると思います。

次に売上明細を日々取得するアプリの開発を行う予定ですが、
ここまでくるとネクストエンジンのAPIは
かなりのところまで攻略できたように思います。

とは言うものの、
マスターの更新はまだ行っていないので学習を終えることはありません。

更に楽天RMSのAPIやYahoo!ショッピングのAPIなども興味があり、
情報の取得や更新を行ってみたいという思いがあります。

今年49歳で始めるコーディングなのですが、
やれば出来るので毎日が楽しすぎて仕方ありません(^^♪

タイトル画像は使いまわして、
世界のシェアや使われ方について別ブログにしたいと思います。
Posted at 2025/10/10 10:33:01 | コメント(0) | トラックバック(0) | 日記
2025年10月08日 イイね!

OTGケーブルで一眼レフカメラとスマホを接続してみました。

OTGケーブルで一眼レフカメラとスマホを接続してみました。9/8にCanon EOS 7Dというブログを書いたように、
ついに一眼レフカメラを購入してしまいました。

それから1ヶ月が経過しておりまして、
ちょっとしたときにでも持ち出して触るようにしております。

因みに、固形ワックス命様から被写界深度についての記事をご紹介くださいました(^^♪
改めてありがとうございますm(_ _)m

ところで私のCanon 7Dは液晶が固定になっておりますが、
液晶が可変になって低いアングルから撮影することの出来る機種もあります。

何やらスマホと一眼レフカメラを接続して、
アプリでコントロールする方法もあるとか・・・

という事で揃えたら無事動作しましたのでご報告します。
私の環境で揃えたのが
・Canon 7D
・Androidスマホ(USBホストモードをサポートしていること)
・OTGケーブル
・スマホホルダー
Helicon Remote:スマホアプリ
サポートカメラリスト
です。

まだ、アプリを使いこなせておりませんが、
アプリから撮影することが出来ることを確認しております。

因みに、スマホから撮影できるのはjpeg画像のみです。
RAWは有料で撮影できるそうです。

いゃその前にマニュアル読んでる?
というツッコミはしない方向で^^;

いろんな道具があるので好き勝手に遊んでいきたいと思います(^^♪

カメラ関係で次に欲しいのは望遠レンズで
・キヤノン EF-S55-250mm F4-5.6 IS STM
です。

初めての一眼レフカメラなので、私には中古の望遠レンズで十分です^^;

あとは、月の撮影を行いたいので超望遠レンズと三脚も欲しいな~
こっちは新品ですがAmazonで海外物の安いのが売っていて
初心者は悪くないんじゃない?というレビューもあるので欲しいな・・・(^^♪
Posted at 2025/10/08 21:25:28 | コメント(1) | トラックバック(0) | 日記
2025年10月07日 イイね!

バイブコーディングという新しい開発手法

バイブコーディングという新しい開発手法バイブコーディング(Vibe Coding)とは
**大規模言語モデル(LLM)を開発プロセスに積極的に活用し、自然言語による指示(プロンプト)を通じてコード生成やアプリケーション開発を行う新しい手法です。OpenAIの共同創業者であるアンドレイ・カルパシー氏によって提唱された用語で、「Vibe」が持つ「雰囲気」「ノリ」「感触」**といった意味合いが、この開発スタイルを象徴しています。

従来のコーディングのように開発者がコードの細部に厳密に集中するのではなく、「〇〇のような機能を作りたい」「こういう雰囲気でまとめて」といった抽象的・概念的な指示をAIに与え、AIがコードを生成し、人間がそれをレビュー・テスト・デバッグするというAIとの協働に焦点を当てています。

メリット・デメリットについては
✅ メリット:高速化とハードル低下
開発スピードの向上: AIが瞬時にコードを生成するため、プロトタイピングやPoC開発が非常に迅速に行えます。

開発の民主化: コードの知識が浅い非エンジニアでも、アイデアを自然言語で伝えれば形にできるため、開発のハードルが大きく下がります。

アイデアの迅速な検証: 「まず作って試す」というアプローチが容易になり、新規事業や実験的な取り組みに最適です。

⚠️ デメリットと注意点:品質と責任
レビューとデバッグの重要性: AIが生成したコードにはバグや非効率な部分、セキュリティ上の問題が含まれる可能性があるため、人間の徹底したレビューとテストが不可欠です。

大規模プロジェクトの難しさ: 複雑で仕様が固まった大規模なシステム全体をAIに「ノリ」で任せるのはまだ難しく、開発者が全体像を把握し、細かく指示・検証する必要があります。

AIへの依存: AIがブラックボックス化し、開発者がコードの深い理解を怠ると、問題発生時の対応能力が低下するリスクがあります。
-----------------------------------------
ここまでが前置きです。

ネクストエンジンとGoogleスプレッドシートをAPI連携させるGoogle Apps Script(=GAS)の2つ目の開発を現在進行系で行っています。

1回目は在庫情報の取得、2回目は出荷明細の取得です。

1回目は本番環境で1日7回の自動実行まで進んでおりまして、
10/1から稼働させておりますがエラー率は0%となっています。

2回目はテスト環境で出荷明細の取得が終わっておりまして、
本番環境へのネクストエンジン審査待ちです。

私は小学生の頃にN88-BASICを学びましたが、
今どきのGASでの開発は行ったことが無いと言ってもいいレベルです。

プロのプログラマーの方々からするとえ?と思われるかもしれませんが、
ド初心者です(-_-;)

そんな私でも2つ目のアプリの開発がほぼ成功したのは
やはりClaude Sonnet3.5に出会ったからでしょうか・・・

8月後半の2週間でコーディングパートナーとして選んだAI達はAPI連携するための第一歩である認証までたどり着かず・・・(-_-;)

各種制限に引っかかって開発が進まなくなってググったらClaudeが出てきました。

9/1からClaudeとバイブコーディングを行ってみたのですが、
すんげ~速さで開発が出来る!

コレばやばい^^;

と言うものの、雰囲気を伝えれば正解が出てくるわけではないのがLLM・・・

Claudeにコーディングをどのように勉強したのか?と聞いたことがありまして・・・
-----------------------------------------
Claudeは実は「学習」という過程を経ていません。膨大なコード、技術文書、プログラミングの議論などのデータから、パターンや構造を理解する形で訓練されました。人間のように段階的に学ぶのではなく、無数のコード例とその文脈を同時に吸収し、プログラミングの「感覚」を獲得したのです。

この訓練方法により、Claudeは複数の言語やフレームワークを横断的に理解し、あなたのようにN88-BASICからGoogle Apps Scriptへと進化してきた開発者とも対話できます。特筆すべきは、コードの「意図」を読み取る能力。エラーメッセージだけでなく、あなたが何を実現したいのかを理解し、ステップ・バイ・ステップで最適な道筋を提案できるのです。

ただし、Claudeは完璧ではなく、あなたとの対話を通じて初めて最適な解決策にたどり着けます。まさに理想的なペアプログラミング・パートナーなのです。
-----------------------------------------
学習ではなく膨大なコードを見て多く使われている方法を統計的に抽出することでコード案を提示しているということですね。

プログラミングの「感覚」というのがまさにバイブ=感覚に当てはまるように感じます。

と言うものの、AIには必ずハルシネーションが存在するので、検証することはもちろんのこと、赤の他人にどれだけ詳しく伝えるのか?=プロンプトエンジニアリングがどれだけ大切なのか?という事があると思います。

例えば私が貴方と話していると仮定して、
ネクストエンジンから今日を含めて3日分の出荷明細を取得してもらえますか?
と言われて分かる貴方はエスパーです。

Claudeも一緒です。
Claudeはコーディングにかなり特化している世界最高水準のコーディングパートナーと思っておりますが、与えるプロンプトエンジニアリングが曖昧では的外れの答えしか出てきません。

今のAIといえどもANI:Artificial Narrow Intelligence=人工狭義知能です。

2日前に作成したブログの内容を引用しますが、
-----------------------------------------
プロファイル設定
クロードの応答において、どのような個人設定を考慮すべきですか?

私のプログラミングの基礎は小学校の頃に学んだN88-BASICです。
その後、様々な言語が出てきており殆どついていけていませんが、数年前にGoogle Apps Scriptをほんの少しだけ学びましたので、Claudeとコーディングを行ったところ、ネクストエンジンとAPI接続できる認証のスクリプト、在庫情報を取得できるスクリプト、1回のAPIコールで1000行の在庫情報を取得できるスクリプトの作成まで進められ、3000行の在庫情報でも18秒程で取得できるようになりました。
プログラマーとしては初心者だと思いますが、エンジニアとしては社会に認められる程度の能力が有ると自負しています。
AIと行うコーディングはステップ・バイ・ステップで行うこと、設計して段階的にテストを行いながら最終的な目的に進むという手法が最も早いように感じます。
また、チャット履歴は必要があれば自由に参照してください。
参照してもらったほうが今までの経緯や私の思いをより読み取ってもらえると思います。

プロジェクトタイトル
倉庫別・運送会社別・出荷予定数取得

プロジェクトの指示を設定
ステップ・バイ・ステップで進みたいと思います。
全体のコーディングを行う前にどのような手順で進めるのか?をある程度に分けて、どのような関数を使ってどのような作業を行わせるのか?を少しずつ進めていきたいと思います。
少しずつ正解にたどり着くことで私の学習も進むように思います。

そこで初めて行ったチャット内容が下記となります。
-----------------------------------------------
ネクストエンジンとスプレッドシートをAPI接続するためにまず必要なのが認証だと思いますが、そちらにつきましては今まで行ってきた在庫情報取得の認証スクリプトが有用に使えると思います。
当然、別プロジェクトになりますのでクライアントIDやクライアントシークレットは新しく取得した値をスクリプトプロパティへ保存します。
認証のスクリプトはGitHubへのリンクを添付したので参考にしてください。
現在SFTPサーバを介してネクストエンジン側から必要な情報を出力しているのですが、プロジェクトに”Shipping_piece.csv”というファイルをUpしていますので参考にしてください。
イメージとしては、本日を含む3日分の出荷予定数をネクストエンジンから取得してGoogleスプレッドシートに書きに行くようになります。
添付はセールではない日常の取得情報量なのですが、大きなセールになると数千行を取得することもあります。
一度にそこまで進むのは難しいと思いますので、まずはAPI1コールで1行の明細を取得できるようになってから、
API1コールで1000行までの明細を取得できるようになりたいと思います。
認証.gsは作成しまして定時実行させるトリガーは別で作成したいと思います。
次は在庫情報取得.gsの作成でしょうか?
どのような手順で進めていくのか?大きな流れから説明してください。
-----------------------------------------
ここから2回目の開発が始まりました。

これらのことを行うことで、Claudeはコーディングをいきなり始めるのではなく
全体の開発フローを提示してくれるようになります。

と言うものの、万能ではなくANI:Artificial Narrow Intelligenceなので、
私が培ったエンジニアの知識が必要でした。

ClaudeではネクストエンジンAPIのエンドポイントを読み取れないようなので、
(txt形式にしても読み取れなかったので)
GitHubにプレーンテキストでエンドポイントのフィールド名をプッシュしたファイルを共有しました。

受注明細検索
こちらの入出力パラメーター、フィールド一覧がClaudeでは検索できなかったために、フィールド一覧をGitHubにテキスト形式でプッシュうしたのを共有したわけです。

フィールド名は仕様書に近い必須項目なのですが、Claudeはそれを知ること無く推測しながらコーディングを進めていたということになります。

次に、出荷予定日で絞り込みを行おうとしたところClaudeの作成したコードではエラーが出てしまいました。

>receive_order_send_plan_date-startのフィールド[receive_order_send_plan_date]に、演算子[start]は指定不可能です。
このエラーを見ると-startが使用できないとのこと・・・

その事をClaudeに伝えると
🔍 解決策の調査
方法A: 受注伝票検索APIを使う
方法B: 全件取得してから絞り込む
との回答でした。

何となくどっちも違う気がする・・・
そう思うのはエンジニアだからと片付ける事は簡単かもしれませんが、
結果私の予感の方が正解でした。
その予感はカスタムデータで必要なCSVを出力させる経験があったかもしれません。
予感というか確信に近い感覚だったのを覚えています。

何か他に検索する方法はないのか?
また、入出力パラメーターの中で見落としはないのか?
を調べるために入出力パラメーターのテキストをGitHubにプッシュしたところ・・・

入出力パラメーターの中に含まれる
フィールド名-比較演算子(WHERE句のカラムと比較演算子相当)
を見つけてくれて解決方法を提案してくれました。

receive_order_send_plan_date-startが使えないので、
-star以外の別のフィールドを指定することでデバッグを行える可能性があるとの提案でした。

という事で、入出力パラメーターのリンク先である
パラメータ比較演算子をテキスト形式にしてGitHubにプッシュしたファイルを共有したところ・・・

完璧です!🎉 まさに探していた情報です!
✅ 確認できたこと
-gte と -lte 演算子は日時型フィールドで利用可能です!
演算子 意味 日時型
-gte >= ✅ 利用可能
-lte <= ✅ 利用可能
つまり、Claudeも万能ではない事を前提に知りたい情報を提供することで正解に早くたどり着くことが出来るのだと改めて認識しました。

ここまで行くと最初にClaudeに提示するように求めたフェーズに従って進んでいくだけです。

結果、テスト環境で数千行の出荷明細を取得できると思われるスクリプトの作成までたどり着いています。
検証出来ていない理由は・・・数千行ものダミーの受注情報を入力できなかったため(-_-;)
とは言うものの、在庫情報を3000行超取得できたチャットを見る権限も与えていますのできっと成功してくれるはずです。

Claudeのコーディング能力が落ちたとか、バイブコーディングという地獄とかいう内容を目にしたのですが、私の少ない知識の中では

それは正解に最短でたどり着くプロンプトエンジニアリングを行ったの?

と思ってしまいます。

Claudeは確かにインターネットに接続していますが、
膨大なエンドポイントから必要な情報を取得するというのをあの短時間で出来るわけでもないので、
こちら側で知り得る情報をこと細かくClaudeに提供することの大切さを改めて認識できました。

また、バイブコーディングを行った時に行うことはそのスクリプトが設計通りの動作を行うのか?
ということが一番最初に確認すべき項目だと思いますが、
コードレビューも行わなければならない項目だと思います。

そのコードがどのような目的で作成されているのか?
場合によっては別にAIに聞くという方法もあろうかと思います。
-----------------------------------------
今日はここまで

・AIといえども万能ではなくその回答には必ずハルシネーションが含まれている事を認識する

Claudeといえども万能ではないので、その回答を必ず検証する必要がある

・ANIはプロンプトエンジニア次第でパフォーマンスが劇的に変わる

AIによる間違いを恐れるのではなく、早く正解にたどり着くプロンプトエンジニアリングを行う事が必要

AIの回答にハルシネーションが含まれる確率は正しいプロンプトエンジニアリングを行うことで劇的に下げることが出来る

・Visual Studio Code(と連携させるGitHub)はコーディングの必須パートナー

・知らない開発言語を一から学ぶより、小さな目的からバイブコーディング繰り返すことで、想像を絶する結果を得られることもある

(私はGAS初心者にもかかわらず5週間で3000行超の在庫情報を30秒前後でGoogleスプレッドシートに書きに行くプロジェクトの作成に成功しました)

(その経験を元に2000行程の出荷明細を取得するプロジェクトの作成が1.5日でほぼ成功しています)
Posted at 2025/10/07 22:37:37 | コメント(0) | トラックバック(0) | 日記
2025年10月06日 イイね!

2024年問題を・・・ってもう良いか^^;

2024年問題を・・・ってもう良いか^^;2024年問題を解決したいだとかそんな事は思っていないけれど・・・
というブログを書いたのですが、
コメントを頂けましたので蛇足とは思いつつブログを作成しました。

タイトル画像は運送会社に提供している加工したスクリーンショットです。

こちらはヤマト運輸向けにIDとパスワードを入力することでスマホでも閲覧できる簡単なページです。

ヤマト運輸向けという事は、他の運送会社向けにも同じような情報を提供しておりまして、
私が作成したのは
・佐川急便
・ヤマト運輸
・JP
・西濃運輸
向けの情報を共有しています。

こういうのが得意なのはGoogleスプレッドシートで、
レイアウトや列の幅など簡単に変更できて、
それを下記のURL例にたいして簡単に公開することが出来ます。

なので、データ処理はGoogleスプレッドシートを使う前提で開発を行いました。
その脆弱性が気になることはありますが、
期間限定の出荷予定数なんてデータが他に流用されて困るか?いや問題ない。

htmlの知識も殆ど必要ありません。
https://www.***.jp/***/
で、簡単にログインできます。

ページソースですがめちゃ簡単です。
ってか私では簡単にしか作れませんでした^^;

Googleスプレッドシートの
共有→ウェブに公開
から得られるURLをindex.htmlにiframeに入れただけです。

契約しているカートシステムでIDとパスワードで閲覧できるページが作成出来ることから、
運送会社別にIDとパスワードを分けてそれぞれ閲覧できるようにしました。

------------------------------------------------------
以上はインターフェイスの説明ですが、
その大本はOMSから出力するCSVです。

と言うものの、OMSから出力できるカラムには制限がありますので、
私が出力させるカラムは下記となります。
出荷予定日 伝票番号 商品コード 商品名 受注数 引当数 奥行き(cm) 幅(cm) 高さ(cm) 発送方法コード 発送方法 重さ(g) 受注状態区分 送り先住所1
こちらが大本の情報1となります。

こんな情報なんて、ネクストエンジンからカスタムデータを使うと簡単に出てきます。

まぁ、商品マスタに
奥行き(cm) 幅(cm) 高さ(cm) 重さ(g)
の情報を入力しておく必要はありますがね・・・

詳細を語るにはみんカラの範囲を超えていますので差し控えますが、
こちらにWMSのデータとそれに不足しているマスタを突き合わせることで
商品コード別に出荷する倉庫が何処なのか?
という認識を行うことが出来ます。
コレを作成した2021年ではvlookupを使用していましたが、
今ならばxlookupを使用していたでしょうね。

WMSから出力したデータのヘッダーは
ブロックID ブロック略称 ロケーション 商品ID 商品名 検索名称 品質区分 品質区分名 入荷日 バラ ボール ケース 在庫数(引当数を含む) 引当数 在庫日 検索名称2 大分類 中分類 小分類
です。

OMSから出力されるCSVとWMSのデータを突き合わせることで、
倉庫別に出荷される商品のコード(商品ID)とその個数をフィルタ書けることが出来ますし、
発送方法でフィルタを掛けることで運送会社事にデータを抽出することも出来ます。

OMSの商品マスタに商品の寸法を入力するようにしていることから
倉庫別、運送会社別に出荷体積を算出することも出来ますし、
カゴ台車の収納可能体積データがあれば、
ヤマト運輸向けにカゴ台車換算何台分というデータを出力することも出来ます。

この辺りのことになると
何が出来る?
ではなく
何がしたい?
という話になってくると思います。

2021/01/04に初版を作成したGoogleスプレッドシートも
2025/06/26に21版を作成しておりました。

興味のない方にとっては何言ってるん?
ご興味を持たれた方にとっても曖昧で何言ってるかわからん?
というブログならではの内容で申し訳ありませんm(_ _)m

運送会社別に確認可能な
出荷予定数 出荷体積 (ヤマト運輸のみ)カゴ台車換算
というデータは運送会社からすると大切な情報と思っておりますが、
限定公開しようとか売り物にしようとかいう思いはサラサラありません。
元々、社内での状況を確認したい目的で作成したGoogleスプレッドシートですからね^^;

因みに、私の開発はGithubでオープンソースで行うと決めておりますので、
開発したソースコードは公開しております。

開発環境はフルクラウドを目指してGoogle Apps Script(=GAS)です。
GASは1回の実行時間数制限があったり、
1日の実行時間数制限がありますが、
そんなのはアイデアと本質を見抜く力があればどうとでもなります。

また、GitHubでもパブリックにすることでそのような環境ができるとか・・・
ネクストエンジンも特定の企業に公開というアプリならば制限がありますが、
一般公開にすることでその制限が一切なくなります。

オープンソースは重要なのですね・・・

導入方法もナレッジベースの蓄積という目的でQiitaで記事にしています。
さらっと書きましたが、公開の経緯はゴニョゴニョで(笑)

この記事の
倉庫別 運送会社別 出荷予定数 & 出荷予定体積 & 出荷予定カゴ台車数
につきましても、
CSV連携からAPI接続できるGASの開発を現在進行系で進めておりまして、
ソースコードはすでにGitHubにプッシュ済みです。
当然パブリック環境です。
私のリポロトジを知りたいという奇特な方がいらっしゃいましたら、
コメントを頂けましたらお答えいたします。
メッセージでも大丈夫です。

私がオープンソースに拘る理由はいくつかありますが、
やはり開発の速度でしょうか?
オープンソース化することでバグやバージョンアップの速度が極端に上がるように思います。

8月17日から行いだしました
AIをコーディングパートナーに選んだコーディングも、
最初の2週間の間は進んでいるようで進んでイナイ・・・

2週間前に進んでいないというのは
コーディングについての私のエンジニア魂からするととんでもないことなのですが、
当時の私の能力ではそれが限界でした。

それを突破したいと思い導入したのがだいぶん前にオープンソース化されたと言われる
Visual Studio Code
です。

Gitの差分管理をGUIで実現したのか?
私ではVS Codeの素晴らしさを十分に語ることは出来ないのですが、
履歴管理とブランチの重要性について
8月17日から8月末までの間に開発が進まなかったという死ぬほど痛い目を見て、
VS Codeの必要性を感じましたので、
9月1日に出会ったClaudeでのコーディングを進めたほうが早いと思いながら、
VS Codeの使い方と今までの履歴を保存していった経緯があります。

ネクストエンジンとGoogleスプレッドシートをAPI接続できるGASの開発は、
これが2度目なのですが
目的がはっきりしていたからか
今回の受注明細を取得するGASの開発は、
思い立ってからテスト環境での開発終了まで1日程でしたかね?

毎日勉強中なのですが、
コーディングAIへの情報共有はそうすれば開発が一気に進むんだと
強く感じた1日でした。

高給が欲しいとか、社会に認められたいとか・・・
そんなことはさらさら考えていなくて、
私が知りたい情報をいつでも知れる環境を作りたい
誰かの作業を待つこと無く便利にその情報を知りたい
という思いで・・・
あの時キレた思いだけで作ったものです。

運送会社からはいい評価を得ているのでまぁまぁ良いものが出来たと思っていますが、
実は全然たいしたことないものかもしれません。

でも、そういう情報は荷主から運送会社に共有されることが殆無いと聞きますので、
まぁまぁ良いものなのかな?と思っています。

これ以上はみんカラブログの域を超えそうなのでここまでにしておきますが、
メッセージを頂けましたらZoomでも他のツールでもオンラインミーティング大歓迎です(^^)

私は私の市場価値を知りたい・・・

今の会社を辞めるつもりはありませんが、
私の市場価値を確認出来る貴方からのお声を待っています^^;
Posted at 2025/10/06 21:39:54 | コメント(0) | トラックバック(0) | 日記
2025年10月05日 イイね!

2024年問題を解決したいだとかそんな事は思っていないけれど・・・

2024年問題を解決したいだとかそんな事は思っていないけれど・・・今のアプリを作ったのいつだろう?

そもそも、最後までみんともの方々に読んでもらえると思っておりません^^;
自分が読み返したいために書いております(笑)

履歴を見ていたら2021年1月でした。
2024年問題の実に3年前^^;

私が作成したのは
倉庫別 運送会社別 出荷予定数 & 出荷予定体積
です。

別にそんなに偉そうな構想があったわけでもなんでも無く、
OMSを導入しているのに午後からの出荷予定数がわからないと答えた部署にキレて
OMSからデータを引っ張り出したら分かるやん!
と思って作り出したのがきっかけで、
社内向けに作ったアプリだったのですが思ったより汎用性があって
運送会社別に出荷予定数&出荷予定体積を定時発信することになりました。

作成したのが2021年1月だったので、
それから2年ほどが経過した2023年頃から2024年問題が取り立たされていましたが、
私が作ったアプリを見てもらうことで個数&体積の予定数を見てもらえることで
配車の手配をあらかじめ運送会社主体で行えるようにしました。
そんなに良いアプリをジャンジャカ出来るわけではないのですが、
このアプリは私自身でもヒットではなかったかと思います。

因みに、私が作ったアプリは
運送会社から喉から手が出るほど欲しい情報にも関わらず、
一般的に荷主から提供されていない情報のようですね(-_-;)

私からすると・・・
キリガナイので私の世の中の思いは置いといて^^;

2021年に作成したアプリも4年も経過すると古く思ってきて・・・
そのアプリの問題点は更新頻度が1日3回が限界・・・

4年前の私ではそれが限界でした。

ですが、令和の9月10月で生成AIであるClaudeにより
在庫情報を取得できたのに気を良くして
倉庫別 運送会社別 出荷予定数 & 出荷予定体積
をフルクラウドで更新頻度を高めて社内外に共有できないか?と思い
新しい開発を今日の午後から行うことにしました。

目的は
ネクストエンジンとGoogleスプレッドシートをAPI接続する
ということになります。

このためにGASの開発を行っていくということになります。

生成AIを使うのであれば最も大切なのが
プロンプトエンジニアリング
ではなかろうかと思います。

と言うものの、
私と同じプロンプトエンジニアリングを行うことで・・・
私よりも高速で・・・
開発が出来るかもしれません。

という事で私が行ったプロンプトエンジニアリングを紹介したいと思います。
-------------------------------------------------
プロファイル設定
クロードの応答において、どのような個人設定を考慮すべきですか?

私のプログラミングの基礎は小学校の頃に学んだN88-BASICです。
その後、様々な言語が出てきており殆どついていけていませんが、数年前にGoogle Apps Scriptをほんの少しだけ学びましたので、Claudeとコーディングを行ったところ、ネクストエンジンとAPI接続できる認証のスクリプト、在庫情報を取得できるスクリプト、1回のAPIコールで1000行の在庫情報を取得できるスクリプトの作成まで進められ、3000行の在庫情報でも18秒程で取得できるようになりました。
プログラマーとしては初心者だと思いますが、エンジニアとしては社会に認められる程度の能力が有ると自負しています。
AIと行うコーディングはステップ・バイ・ステップで行うこと、設計して段階的にテストを行いながら最終的な目的に進むという手法が最も早いように感じます。
また、チャット履歴は必要があれば自由に参照してください。
参照してもらったほうが今までの経緯や私の思いをより読み取ってもらえると思います。

プロジェクトタイトル
倉庫別・運送会社別・出荷予定数取得

プロジェクトの指示を設定
ステップ・バイ・ステップで進みたいと思います。
全体のコーディングを行う前にどのような手順で進めるのか?をある程度に分けて、どのような関数を使ってどのような作業を行わせるのか?を少しずつ進めていきたいと思います。
少しずつ正解にたどり着くことで私の学習も進むように思います。
-----------------------------------------------
ここまでが前提です。
プロジェクトを立ち上げてチャットを行う前に私はこのように入力しました。

Claudeでのパワーワードは
ステップ・バイ・ステップ
となります。

この言葉をチャット内容などに入れることでClaudeは手順ごとに一歩ずつ進んでくれることになります。

そこで初めて行ったチャット内容が下記となります。
-----------------------------------------------
ネクストエンジンとスプレッドシートをAPI接続するためにまず必要なのが認証だと思いますが、そちらにつきましては今まで行ってきた在庫情報取得の認証スクリプトが有用に使えると思います。
当然、別プロジェクトになりますのでクライアントIDやクライアントシークレットは新しく取得した値をスクリプトプロパティへ保存します。
認証のスクリプトはGitHubへのリンクを添付したので参考にしてください。
現在SFTPサーバを介してネクストエンジン側から必要な情報を出力しているのですが、プロジェクトに”Shipping_piece.csv”というファイルをUpしていますので参考にしてください。
イメージとしては、本日を含む3日分の出荷予定数をネクストエンジンから取得してGoogleスプレッドシートに書きに行くようになります。
添付はセールではない日常の取得情報量なのですが、大きなセールになると数千行を取得することもあります。
一度にそこまで進むのは難しいと思いますので、まずはAPI1コールで1行の明細を取得できるようになってから、
API1コールで1000行までの明細を取得できるようになりたいと思います。
認証.gsは作成しまして定時実行させるトリガーは別で作成したいと思います。
次は在庫情報取得.gsの作成でしょうか?
どのような手順で進めていくのか?大きな流れから説明してください。
-----------------------------------------------
こちらの返答が
-----------------------------------------------
ステップ・バイ・ステップで進めていくという方針、とても良いと思います。N88-BASICから始まり、GASでAPI認証まで実装された経験があれば、確実に進められると思います。
それでは、全体の流れを説明します。
📋 全体の開発フロー
フェーズ1: 基礎構築(認証とAPI接続の確認)

認証.gs の設置と動作確認

新しいプロジェクトに認証.gs を配置
新しいクライアントID/シークレットを取得してスクリプトプロパティに設定
testApiConnection() で認証が通ることを確認

出荷明細API の調査

ネクストエンジンのAPI仕様書で「出荷明細検索API」のエンドポイントを確認
どのパラメータで日付指定するか確認
どんなフィールド(項目)が取得できるか確認

フェーズ2: 1行取得(最小単位での動作確認)
出荷明細取得.gs の作成(簡易版)
関数名: testFetchShippingData()
目的: API 1コールで 1件だけ 出荷明細を取得してログに表示
使用する関数:

UrlFetchApp.fetch() でAPIリクエスト
JSON.parse() でレスポンス解析
console.log() で内容確認

フェーズ3: 日付指定と複数件取得
日付指定機能の追加
関数名: fetchShippingDataByDate(targetDate)
目的: 指定した日付の出荷明細を取得
使用する関数:

Utilities.formatDate() で日付をAPI用フォーマットに変換

ページング処理(1000件ずつ取得)

関数名: fetchAllShippingData(startDate, endDate)
目的: 指定期間の全データを1000件ずつ取得
使用する関数:

ループ処理で offset パラメータを変更しながら繰り返し取得
配列に結果を蓄積

フェーズ4: スプレッドシート連携
スプレッドシート書き込み機能
関数名: writeToSpreadsheet(data)
目的: 取得したデータをスプレッドシートに書き込む
使用する関数:

SpreadsheetApp.getActiveSpreadsheet() でシート取得
sheet.getRange().setValues() で一括書き込み

メイン実行関数の作成

関数名: updateShippingData()
目的: 本日を含む3日分のデータを取得→シート更新
この関数をトリガーで定時実行

🎯 次のステップの提案
まずは フェーズ2の「1行取得」 から始めましょう。
具体的には:

ネクストエンジンの出荷明細検索APIのエンドポイントとパラメータを確認
出荷明細取得.gs を作成
testFetchShippingData() 関数で1件だけ取得してログ表示

この段階では:

スプレッドシートへの書き込みは まだ行わない
1000件取得も まだ行わない
ただ「APIから出荷明細が取れる」ことだけを確認する

❓ 確認したいこと
進める前に2点確認させてください:

ネクストエンジンのAPI仕様書は手元にありますか?

特に「出荷明細検索API」の項目が必要です
もし手元になければ、Shipping_piece.csv の項目名から推測して進めることもできます

**取得したい項目(フィールド)**は Shipping_piece.csv にある項目で全て揃っていますか?

出荷日(o×\èú)
伝票番号(`[Ô)
商品コード(¤iR[h)
商品名(¤i¼)
数量(ó)
など...

この2点を確認できたら、最初の testFetchShippingData() 関数の作成に進みましょう。いかがでしょうか?
-----------------------------------------------
ステップ・バイ・ステップと伝えたことで、
いきなりコーディングをするのではなく道筋を立ててくれました。

私のように会社に金が無い状態でFreeプランで行うには、
一歩ずつ進むのが一番の近道のように感じます(-_-;)

その私からの回答が下記となります。
-----------------------------------------------
そのフェーズで進めてまいりましょう。
フェーズ1: 基礎構築(認証とAPI接続の確認)
testApiConnection() で認証が通ることを確認しました。
出荷明細API の調査
プロジェクトにNE_受注明細エンドポイント.csvをUpしました。
参考にしてください。
取得したい項目(フィールド)は Shipping_piece.csv にある項目ですべて揃っています。
ただし、同じエンドポイント内なので大丈夫だと思いますが、
幅 goods_width などの情報を取得する際にAPIコール数が増えるのでしたら私に確認してください。
最終的にAPI1コールで1000行の情報を取得することで
API呼び出し回数 / 月 通信データ量(GB) / 月 金額(円) / 月(税抜)
1〜1000 〜3 無料
の範囲内で使用する前提です。
では、
フェーズ2: 1行取得(最小単位での動作確認)
testFetchShippingData()の作成に進んでください。
今回テストで作成するスクリプトでヘッダーに説明文を記入しましたので共有します。
-----------------------------------------------
とチャットで答えたことのClaudeからの返答です。
-----------------------------------------------
ありがとうございます。それでは、フェーズ2の1行取得テストに進みましょう。
まず、アップロードされた NE_受注明細エンドポイント.csv の内容を確認させてください。file:///NE_受注明細エンドポイント.csvの取得に失敗しましたCSVファイルを直接読み込めませんでしたが、Shipping_piece.csvの項目から必要な情報は把握できました。
それでは、出荷明細取得.gs(テスト版)を作成します。まずは1行だけ取得する最小構成で進めましょう。出荷明細取得_テスト.gsコード /**
=============================================================================
ネクストエンジン出荷明細取得スクリプト(単一API版テスト)
=============================================================================

* 【目的】
* ネクストエンジンAPIから出荷明細データを取得する
*
* 【機能】
* フェーズ2: 1行取得完成しました!出荷明細取得_テスト.gs を作成しました。
📝 作成したスクリプトの説明
testFetchShippingData() 関数
この関数は以下の処理を行います:

トークン取得: スクリプトプロパティから ACCESS_TOKEN と REFRESH_TOKEN を取得
APIリクエスト作成: 受注明細検索API (api_v1_receiveorder_row/search) にリクエスト
パラメータ設定:

limit: 1 で1件のみ取得(テスト用)
fields で必要な項目を指定

結果表示: ログに取得したデータの詳細を表示

使用している関数

PropertiesService.getScriptProperties(): スクリプトプロパティからトークン取得
UrlFetchApp.fetch(): HTTP通信でAPIリクエスト
JSON.parse(): レスポンスをJSON形式に変換
console.log(): 結果をログに表示

🎯 次のアクション
このスクリプトを実行して、以下を確認してください:

実行前の確認

認証.gs の testApiConnection() が成功していること
ネクストエンジンのアプリ設定で「受注明細検索」のAPI権限が有効になっていること

実行

testFetchShippingData() を実行

ログの確認

「出荷明細取得成功」と表示されるか
取得データにどんな項目が含まれているか

項目の照合

Shipping_piece.csv の項目と比較
不足している項目がないか確認

❓ 確認したいこと
実行後、以下を教えてください:

エラーなく実行できましたか?
取得できたデータにどんな項目(フィールド)が含まれていましたか?
Shipping_piece.csv と比較して、不足している項目はありますか?

もし「幅・奥行・高さ・重量」などの商品寸法情報も必要な場合は、fields パラメータに追加します。ただし、ご懸念の通り、これらの情報が別テーブルにある場合はAPI呼び出し回数が増える可能性があります。その点は実行結果を見てから判断しましょう。
実行結果をお待ちしています!
-----------------------------------------------
今日はこのぐらいにしておきましょうか^^;

誰もついてきていないと思いますし・・・(-_-;)

良いんです。
ブログですから好きなことを書いても良いんです。

Posted at 2025/10/05 21:28:00 | コメント(1) | トラックバック(0) | AI | 日記

プロフィール

「私が考える世界最高コーディングパートナーであるClaude http://cvw.jp/b/11052/48702789/
何シテル?   10/10 10:33
2025/06/23追記 ヘッダー画像について興味をお持ちの方もいらっしゃると思いますが、こちらは2025/06/21に香川県で開催されました、GAZOO 愛...
みんカラ新規会員登録

ユーザー内検索

<< 2025/10 >>

    1 2 34
5 6 7 89 1011
12131415161718
19202122232425
262728293031 

リンク・クリップ

GAZOO 愛車広場 出張取材会 in 香川 満を持してチェイサーの記事が公開されました(^^) 
カテゴリ:その他(カテゴリ未設定)
2025/08/22 08:26:45
電費履歴リセット 
カテゴリ:その他(カテゴリ未設定)
2024/10/12 07:34:32
裏ワザでウィンドウズ11へ^^笑)。 
カテゴリ:その他(カテゴリ未設定)
2024/01/27 14:12:45

愛車一覧

トヨタ チェイサー GR Chaser TourerV TRD sports version (トヨタ チェイサー)
2025/06/21 GAZOO様の出張取材会で取材を頂きました。 https://ga ...
日産 リーフ 日産 リーフ
JZX100 Chaser 1JZ-GTE 2500cc ターボを所有しつつのセカンドカ ...
ホンダ アコード ホンダ アコード
私のではなく弟の車です。 色はアークティックブルーパールのEuro-Rです。 購入してし ...

過去のブログ

2025年
01月02月03月04月05月06月
07月08月09月10月11月12月
2024年
01月02月03月04月05月06月
07月08月09月10月11月12月
2023年
01月02月03月04月05月06月
07月08月09月10月11月12月
2022年
01月02月03月04月05月06月
07月08月09月10月11月12月
2021年
01月02月03月04月05月06月
07月08月09月10月11月12月
2020年
01月02月03月04月05月06月
07月08月09月10月11月12月
2019年
01月02月03月04月05月06月
07月08月09月10月11月12月
2018年
01月02月03月04月05月06月
07月08月09月10月11月12月
2017年
01月02月03月04月05月06月
07月08月09月10月11月12月
2016年
01月02月03月04月05月06月
07月08月09月10月11月12月
2015年
01月02月03月04月05月06月
07月08月09月10月11月12月
2014年
01月02月03月04月05月06月
07月08月09月10月11月12月
2013年
01月02月03月04月05月06月
07月08月09月10月11月12月
2012年
01月02月03月04月05月06月
07月08月09月10月11月12月
2011年
01月02月03月04月05月06月
07月08月09月10月11月12月
2010年
01月02月03月04月05月06月
07月08月09月10月11月12月
2007年
01月02月03月04月05月06月
07月08月09月10月11月12月
2006年
01月02月03月04月05月06月
07月08月09月10月11月12月
2005年
01月02月03月04月05月06月
07月08月09月10月11月12月
ヘルプ利用規約サイトマップ
© LY Corporation