ヒデノリのブログ一覧

アパートの近くにヤマト運輸の営業所があるのですが、
営業所の方から移転すると言われましたので移転先を見てきました。

工事が遅れていると聞いて行ったのですが・・・

敷地も建物も出来てるやん(・・;)

で、副所長に移転時期を聞いたら来年の2月とか・・・

アパートからちょっと遠くなるのが前年ですが、
新しい建物って良いですね(^^)

昨日、If it ain't broke, don't fix itというブログで（壊れていないなら、いじるな）という回答をClaudeから得たとUpしました。

一方、SRE的視点では安定性を求めるために改良する事もあります。

"Fix it before it breaks"
（壊れる前に強化せよ）

SREの視点とエンジニアリングの哲学
あなたの直感は正しいです。両方とも真実なんです：
"If it ain't broke, don't fix it"
= 不要な変更でリスクを増やすな
SREの改善思想
= 壊れる前に強化せよ
この2つは矛盾していません。区別すべきは変更の性質です：

❌ 避けるべき変更:
- OAuth2ライブラリへの全面移行（アーキテクチャの刷新）
- 動作している認証ロジックの書き換え
- 新しい依存関係の追加

✅ 推奨される改善:
- リトライ機能の追加（防御的プログラミング）
- エラーハンドリングの強化
- 既存ロジックはそのまま、保護層を追加

実践的な提案
ステップ1: NE_在庫情報取得にリトライ機能を追加
NE_出荷予定数取得で実装済みのリトライ機能を、在庫情報取得にも横展開する。
メリット:

既に検証済みのコード（出荷予定数で実績あり）
Google側の一時障害に対応できる
既存ロジックに手を入れない（ラッパーとして追加）

リスク: ほぼゼロ

新しい技術ではない
既に片方のプロジェクトで動作確認済み

ステップ2: 2つのプロジェクトで共通化
両方で安定したら、共通ライブラリ化を検討（将来的に）。

最後に

「毎日一歩でも良いから前に進みたい」

あなたが最初に仰ったこの言葉、完全に実現されました：

10/1: 在庫情報取得の安定稼働開始
10/23 午前: リトライ機能の検討開始
10/23 午後: テスト→実装→本番適用完了

わずか数時間で、本番環境の改善を完遂されました。
---------------------------------------------------------
という事でOAuth2の実装は行わなかったのですが、
在庫情報取得のプロジェクトにSRE的視点でリトライ機能の実装を行うことになりました。

しかも、既存スクリプトは修正せずに新しいスクリプトをプロジェクトに追加するという方法を採用しましたのでロールバックが容易に行うことが出来ました。

Geminiに認証について聞いたところOAuth2ライブラリを紹介されたのですが、
結局認証まで進むことが出来ませんでした(-_-;)

なんでGeminiってコーディングが出来ると言われているのでしょうね？

確かに、
ハードコーディングされている箇所をスクリプトプロパティに修正して下さい
というのは得意でした。

ところがバイブコーディングを一から始めるのは苦手な印象があります。

という事で、私が思う世界最高峰のコーディングパートナーに
OAuth2ライブラリの導入に聞いたところ予想外の答えでした。

私
-------------------------------------------
いままで、ネクストエンジンとGoogleスプレッドシートをAPI接続できるGASの開発を行ってきました。
Claudeのお陰でファーストステップとして認証を行うスクリプトの作成までたどり着くことが出来ました。
スクリプトを共有しますので御覧ください。
一方、Google Apps Script 公式のOAuth2ライブラリを使うと良いという意見がありました。
そのことについてClaudeはどのように考えますか？
-------------------------------------------
Claude
-------------------------------------------
既存の認証スクリプトを拝見しました。N88-BASICから始まり、GASで実用的な認証システムを構築されたこと、素晴らしいですね。
OAuth2ライブラリについての見解
現時点では導入を推奨しません。 理由は以下の通りです:
1. 現在のコードが正常に動作している
認証フローが確立され、トークンの取得・更新・保存が機能しています。「動いているものを壊すな」という原則は、特にアジャイル開発では重要です。
2. 学習曲線とのバランス
OAuth2ライブラリは確かに便利ですが、新しいライブラリの仕様を学ぶコストが発生します。現在のコードは:

認証フローが可視化されている
トラブルシューティングがしやすい
カスタマイズの自由度が高い

3. 段階的な改善の機会
今後、以下のような課題が出てきた時に検討すべきです:

トークン更新の自動化がうまく動かない
複数のAPIエンドポイントで認証管理が煩雑になる
セキュリティ要件が高まる

結論
現在のシステムは**「枯れた技術」として安定稼働**しています。
エンジニアリングの格言:

"If it ain't broke, don't fix it"
（壊れていないなら、いじるな）

今やるべきこと:

現在のシステムを信頼して運用継続
エラーログを充実させて監視体制を整える
問題が顕在化したら、その時に最適な解決策を選ぶ
-------------------------------------------
既存のスクリプトが動作していることからOAuth2ライブラリの導入は否定的でした。

これはポイントが高い。

因みに、枯れた技術というのは枯れたという言葉から
枯れ葉を想定して否定的な認識を持ちがちですが
IT系では全く逆の意味として捉えられています。

「枯れた技術」とは、広く使われて信頼性が高まり、メリット・デメリットが明確になった成熟した技術のことです。これは否定的な意味ではなく、「安定性が高く、不具合も含めてノウハウが蓄積されている」という意味で、IT分野などで称賛の意を込めて使われることがあります。

挙げていただいた格言
"If it ain't broke, don't fix it"
（壊れていないなら、いじるな）
も心に染み渡ります。

因みに、
Claudeを使い、ネクストエンジンとGoogleスプレッドシートをAPI連携させる：認証編
につきましてはQiitaで公開しておりますので興味がありましたら御覧くださいm(_ _)m

ネクストエンジンとGoogleスプレッドシートをAPI接続できるGASの開発で、
認証のスクリプトをわたしたところ
----------------------------------------------------
この度は、ネクストエンジンAPIとの認証に成功されたとのこと、誠におめでとうございます。また、試行錯誤の末に完成した貴重なコードを共有いただき、ありがとうございます。

共有いただいたコードは、機能ごとに細かく関数が分割され、コメントやガイドも非常に丁寧で、素晴らしい完成度です。特に、機密情報をスクリプトプロパティで管理し、スタンドアロンスクリプトとして作成されている点は、セキュリティと再利用性の観点から非常に優れた設計思想だと感じました。

この素晴らしいコードを、さらに堅牢で、メンテナンスしやすく、そして拡張しやすくするための改善案をいくつか提案させていただきます。
----------------------------------------------------
なんというか・・・
凄い俺はやるぜ感が満載^^;

考えてみればOAuth2ライブラリからしてハルシネーションが発生していました(-_-;)

Gemini 2.5 Pro・・・
コーディングできるんじゃないんか～い！(-_-;)

Claudeでバイブコーディングを行っておりますが、
もっとAIのことを知ったほうが良いのでは？
と思いまして図書館で借りてきたのがこれらの本です。

これらを呼んでバイブコーディングが上手くいくわけではないのですが、
AIとは？とかAIの歴史を知りたくて読んでいます。

当然、Claudeの5時間制限や面白くない会議の間に（笑）