辞書データ処理ツール（S04）のGoogle Apps Scriptが巨大化し、メンテナンスが困難になってきた。すべてのツール機能が単一のファイルに詰め込まれており、関数が1000行を超えていた。 リファクタリングの目的は、コードを論理的に整理し、各ツールの責任を明確にすることだった。新しい構造は3つのレイヤーに分けられた： 第一層：Core UI/Helpers 第二層：Tool-Specific Functions 各ツールはさらに2つのセクションに分割： 第三層：Data Access この構造により、関数の配置が明確になった。例えば、Expression & PN Toolでは： リファクタリング中、関数の配置ミスをいくつか発見した。例えば、「Duplicate Finder」ツールの内部ロジック関数が、「CAT Checker」のセクションに紛れ込んでいた。新しい構造では、各関数が論理的な場所に配置されている。 コメントブロックも標準化した： 現在、S04スクリプトは明確に整理されている。新しいツールを追加する際も、どこに配置すべきか一目瞭然だ。各ツールは独立しており、相互に干渉しない。この経験から、早期のモジュール化の重要性を学んだ。

ダッシュボードのTask Schedulerバッジが更新されない問題を調査中、GitHub APIの重要な特性を発見した。 問題は、CSVファイルを更新した後、ダッシュボードのバッジ表示（「Today」「Yesterday」など）が即座に更新されないことだった。Mongolian Headwordsのバッジは1-3秒で更新されるのに、Task Schedulerは数分かかる。 原因は、使用していたAPIエンドポイントの違いだった。当初、commitsリストAPIを使用していた： このエンドポイントには15-60秒の伝播遅延がある。GitHubが内部的にコミットリストをキャッシュし、定期的にしか更新しないためだ。 解決策は、2段階のアプローチだった： ステップ1：Content APIで最新のSHAを取得 Content APIは1-3秒で更新され、常に最新のSHA値を返す。 ステップ2：SHA値で直接コミット情報を取得 この方法により、コミットリストAPIの遅延を回避しつつ、完全なコミットメタデータ（日時、著者、メッセージ）を取得できる。 ダッシュボードのアーキテクチャは、デュアルAPI戦略を使用するようになった： キャッシュメカニズム（5分TTL）も正しく機能していることを確認した。問題はキャッシュではなく、APIエンドポイントの選択だった。 現在、Task Schedulerバッジは、Mongolian Headwordsと同じ速度（1-3秒）で更新される。この経験から、APIの各エンドポイントの特性を理解することの重要性を学んだ。

ダッシュボードのゲージチャート2と3は、静的なベースラインに対する進捗を測定する特殊なメトリクスだ。Gauge 1（総エントリ数）とは異なり、これらは時間経過に基づく評価を行う。 Gauge 2（Backlog Pressure）は、未処理データの蓄積状況を測定する。理想的には50%（中立）だが、14日以上更新がないと黄色ゾーン、30日以上で赤ゾーンに突入する。 実装の鍵は、Script Propertiesに保存されたベースラインタイムスタンプとの比較だった： Gauge 3（Chain Completion）は、5段階のデータ処理チェーン（S02→S03→S04→S05→S06）の完了状況を追跡する。各段階が完了すると20%ずつ増加する。 当初、メニューの不安定性にも悩まされた。Code.gsのメニュー構築関数が、他の関数と競合していた。解決策は、メニュー初期化をonOpen()トリガーから分離し、専用の関数に移動することだった。 ベースライン情報の管理も重要だった。管理者が各フォルダのベースラインタイムスタンプを設定・表示できる関数を追加した： 現在、Gauge 2と3は正確に動作しており、プロジェクトの健全性を視覚的に示している。時間ベースの評価メトリクスは、データ処理の遅延を早期に検出するのに有効だ。

Inventory自動化システムで、チェーン実行が正しく動作しないバグを発見した。5つのサブフォルダを順番に処理するはずが、最初のフォルダを繰り返し処理していた。 問題は、100ファイル以上あるフォルダの処理が完了しても、次のフォルダに進まず、同じフォルダを最初から処理し直すことだった。 調査の結果、Phase 2（フォルダ処理完了）のコードに問題があることがわかった： フォルダ処理が完了すると、stateKey（進捗状況を保存するキー）は削除されるが、inventoryChainIndex（現在処理中のフォルダインデックス）はインクリメントされなかった。そのため、次回実行時に同じフォルダが再度処理された。 修正版： この修正により、フォルダ処理が完了すると、システムは自動的に次のフォルダに進むようになった。 テスト時には、Logシートに「Chain advanced to index X」というメッセージが表示されることを確認した。これにより、チェーンが正しく前進していることが視覚的に確認できる。 現在、完全なInventoryチェーンは5つのサブフォルダすべてを順番に処理できる。日次トリガーでtriggerFullInventoryを実行すると、システムは自動的に次のフォルダに移動し、すべてのフォルダが処理されるまで継続する。

Bawden辞書の見出し語を小文字に変換する処理で、3段階のワークフローを設計した。このプロセスは、AIと人間の協働作業の好例だ。 第一段階：自動的な固有名詞フラグ付け 既存のGASツールが、大文字で始まる見出し語を検出し、固有名詞の可能性があるものにフラグを立てる。このツールは、文脈も考慮する。例えば、文頭に来る単語は自動的に大文字になるため、それを考慮する。 第二段階：人間による確認 フラグが立てられた見出し語について、人間がチェックボックスで確認する。本当に固有名詞なのか、それとも通常の名詞なのか。例えば、「Moron River」は固有名詞だが、「morning」は違う。 第三段階：自動的な小文字変換 チェックボックスがオフのもの（固有名詞でないと確認されたもの）だけを小文字に変換する。新しいGASツールがこの処理を実行する。 当初、私は過度に複雑な仕様書をGemini用に作成しようとしていた。しかし、これは間違ったアプローチだった。Geminiに必要なのは、詳細な仕様書ではなく、明確な機能要求と反復的なデバッグだ。 正しいアプローチ： 「チェックボックス生成機能と小文字変換機能を追加してください」 → テスト → バグを報告 → 修正 → 再テスト 間違ったアプローチ： 「以下の詳細な仕様に従って、完璧なツールを一度で作成してください」 → 複雑すぎて実装できない → または、仕様を誤解して間違ったものを作る このワークフローが完成した後は、Bawden辞書の本格的な処理が始まる： 同時に、NOTE欄に含まれる複合語、イディオム、諺も、別途定義された「Idiom-Collocations-Processing-Guide」に従って処理する。 このワークフロー設計から学んだのは、AIを使う際の「仕様書より反復」という原則だ。完璧な計画を立てるより、小さく始めて改善していく方が効率的だ。

S04データ処理ツールに新しい機能「Headword Case Converter」を追加する際、複雑なUI動作バグに遭遇した。 新しいツールをサイドバーフレームワークに統合したところ、ボタンクリックが他のツールのボタンも無効化してしまうという問題が発生した。Expression & PN Toolのボタンをクリックすると、Proper Noun Case Converterのボタンまで無効化された。 問題は、toggleButtons()関数の呼び出し方にあった。コードには2つのバージョンのrunExpressionTask()関数があり、2番目のバージョンが特定のボタンIDを渡さずにtoggleButtons(true)を呼んでいた。 解決策は、重複した関数定義を削除し、すべてのツール関数が特定のボタンIDを渡すようにすることだった。 もう一つの問題は、ヘッダー設定の間違いだった。新しいツールはMNとPN?カラムを想定していたが、実際のシートには異なるヘッダーがあった。Google Sheetsの実際の構造を確認し、正しいカラムインデックスを使用するように修正した。 開発プロセスでも学びがあった。最初の数回の反復で、不完全なコードが提供されていた。コードの一部だけが変更され、他の部分が欠落していた。この問題を回避するため、以下の新しいプロトコルを採用した： 現在、S04 Headword Case Converterは完全に機能している。ボタンの分離も正しく動作し、各ツールは独立して実行できる。この経験から、UI状態管理の重要性と、完全なコード提供の必要性を学んだ。

伝統モンゴル文字の表示・編集ツールであるTraMN Viewerを、プロジェクトの他のツールと視覚的に統一するため、大幅なデザイン改修を行った。バージョン1.1から1.2への更新だ。 改修の中心は、GAS Dashboard v3.6で確立したデザインパターンの導入だった。ブラウン系のグラデーション（#B98D63、#8E6A46）、CSS変数ベースのスペーシングシステム（–spacing-xsから–spacing-2xlまで）、統一されたカードの影効果、ボタンのホバーエフェクトなどだ。 新たに4カラムの統計グリッドも追加した。総記事数、総文字数、モンゴル文字数、著者数を表示するカードで、レスポンシブデザインにも対応している。画面幅が狭くなると、4カラムが2カラム、さらに1カラムへと自動的に切り替わる。 技術的に興味深かったのは、統計カードの視覚的なバランス調整だ。最初の実装では、カードの縦の余白が大きすぎて（16px）、情報密度が低く見えた。これを12pxに減らし、フォントサイズも微調整（値を24pxから22px、ラベルを12pxから11pxへ）することで、より引き締まった印象になった。最小高さを70pxに設定することで、極端に小さくなることも防いだ。 重要なのは、これらのデザイン変更が既存の機能（縦書きテキストレンダリング、ラテン文字の埋め込み、記事のCRUD操作、カスタムフォント読み込み、カラムレイアウト制御など）に一切影響を与えなかったことだ。デザインとロジックの分離が適切に行われていた証拠だ。 今後は、Prof. Erdenebilegの語源ビューアやNaranchimegの社会言語学パネルにも同じデザインシステムを適用し、プロジェクト全体の視覚的一貫性を完成させる予定だ。

伝統モンゴル文字ビューアの開発で、テキスト折り返し処理に長期間苦労していた。最終的に、CSS Columnsレイアウトモデルが最も安定した解決策だと判明した。 当初、Flexboxを試みた。親要素にdisplay: flexとflex-direction: columnを指定し、子要素を縦に並べる。しかし、長いテキストが画面外に突き抜けてしまい、折り返しを制御できなかった。 次に、white-space: nowrapとinline-blockの組み合わせを試した。これである程度機能したが、複数記事を表示する際、記事間の区切りが不明瞭になった。 CSS Columnsモデルの実装： この方法の鍵は、記事全体の高さを正確に計算することだった。行数、行の高さ、パディングを組み合わせて総高さを算出し、それをheightプロパティに設定する。 column-fill: autoにより、テキストは自動的に次のカラムに折り返される。overflow-x: autoにより、すべてのカラムが画面に収まらない場合、横スクロールが可能になる。 box-sizing: border-boxも重要だった。これにより、パディングとボーダーが指定されたheightに含まれる。デフォルトのcontent-boxでは、パディングが高さに追加され、計算が狂ってしまう。 現在のビューアはシンプル版で、最新の記事のみを表示する。完全版では記事リスト、追加・編集機能を統合する必要があるが、核心のテキスト表示ロジックは完成した。この安定したCSS基盤の上に、残りの機能を構築していく。

辞書プロジェクトのダッシュボード（v3.6）と、それが依存するS06ライブラリの統合作業で、一連の複雑なバグに遭遇した。 最初の問題は、関数の欠落だった。ダッシュボードのフロントエンドが呼び出している関数が、バックエンドのコードに存在しなかった。これは、コードの異なるバージョンが混在していたことが原因だった。バージョン管理の重要性を改めて認識させられた。 次に、関数呼び出しの名前の不一致があった。フロントエンドはfunctionA()を呼んでいるのに、バックエンドではfunctionB()という名前で定義されていた。JavaScriptは動的型付け言語なので、このような間違いがコンパイル時に検出されない。 さらに、OAuth権限スコープのエラーも発生した。Google Apps Scriptは、使用するGoogle APIに応じて適切な権限を要求する必要がある。権限が不足していると、実行時にエラーが発生する。appsscript.jsonのマニフェストファイルを正しく設定することが重要だ。 これらの問題を一つずつ解決していく過程で、「Staging Folder to Google Doc Logbook」ワークフローが動作するようになった。これは、Google Driveのステージングフォルダから特定のGoogle Docにコンテンツを同期する機能だ。ライブラリ接続とコア権限が正しいことが確認された。 しかし、最終ステップの「Doc to GitHub Logbook」同期（runFullSync）はまだ動作していない。おそらく、Google DocからMarkdownへの変換ロジックにエラーがあると思われる。次のセッションでは、convertDocToMarkdown_関数の実行ログを分析し、具体的な失敗箇所を特定する必要がある。 デバッグ作業は地道だが、システムを確実に動作させるためには不可欠だ。一つ一つの問題を丁寧に解決していくことで、最終的には安定したシステムが完成する。

ダッシュボードでGoogle Gauge Chartを使用した際、パーセント記号（%）が正しく表示されないという奇妙な問題に遭遇した。 問題は、Google ChartsのNumberFormat機能を使用すると、一時的に%記号が消えたり、チャートがちらつく（flickering）ことだった。これはブラウザのレンダリングタイミングと関係していた。 最初の解決策として、NumberFormatを適用した後、setTimeout()で若干の遅延を入れてから再描画する方法を試したが、これは根本的な解決にはならなかった。 最終的に採用したのは、可視性トグル方式だった。NumberFormatを適用する前にチャートを一時的に非表示にし、フォーマット適用後に再び表示する。 この方法により、ユーザーには完全にレンダリングされたチャートだけが表示され、ちらつきが完全に解消された。可視性の切り替えは数ミリ秒で完了するため、ユーザーエクスペリエンスへの影響はない。 この問題は、Google Chartsライブラリの内部的なレンダリングパイプラインと関係していると思われる。NumberFormatの適用とチャートの描画が非同期で実行されるため、タイミングによっては不完全な状態が表示されてしまう。 現在、ダッシュボードの3つのゲージチャート（Backlog Pressure、Chain Completion、Quality Score）はすべて正しく%記号付きで表示されており、ちらつきもない。