ResourcePadコンポーネント（Google Sitesに埋め込まれる研究リソースのリスト）で、持続的で非常にフラストレーティングなレイアウト問題が発生した。 問題は、Google Sitesのiframe内でコンポーネントが表示される際、レイアウトが崩れることだった。単独のページでは正しく表示されるが、埋め込まれると壊れる。 最初、iframeの問題だと思い、様々なiframe設定（幅、高さ、スクロール設定）を試した。しかし、どれも効果がなかった。次に、キャッシュの問題を疑い、デプロイメント設定やバージョン番号を変更した。それも無駄だった。 真の原因は、コンポーネント自体のCSSにあった。複数のCSSルールが衝突し、Google Sitesの環境でのみ問題を引き起こしていた。 具体的には、親要素のmax-width設定と子要素のwidth: 100%の組み合わせが、iframeの制約と相互作用して、予期しない結果を生んでいた。 解決策は、より具体的なレイアウトコンテナを使用することだった。Flexboxレイアウトを適用し、明示的な幅の制約を削除した。 このバグの診断が困難だったのは、問題が環境依存だったからだ。ローカルテストでは再現せず、Google Sitesの特定の条件下でのみ発生した。最終的には、ブラウザの開発者ツールで実際のレンダリング結果（outerHTML）を調べることで、真の原因を特定できた。 現在、ResourcePadはGoogle Sites内で正しく表示される。この経験から、環境依存の問題には、実際の環境でのデバッグが不可欠だということを学んだ。

モンゴル語辞書の編纂作業で、Google Sheetsに蓄積された大量のデータを効率的に処理する必要が出てきた。そこで、Google Apps Script(GAS)を使った専用ツールを開発することにした。 当初はシンプルなスクリプトを考えていたが、実際に作業を進めるうちに、データのクリーニング、重複チェック、フォーマット統一など、複数の機能が必要になってきた。最終的には、サイドバーUIを持つ統合ツールとして仕上げることができた。 特に苦労したのは、モンゴル語(キリル文字)と日本語が混在するデータの処理だ。文字コードの問題で、GitHub経由でCSVをやり取りする際に文字化けが発生することがあった。UTF-8エンコーディングの徹底と、適切なヘッダー処理の実装で解決できたが、多言語データの扱いは思った以上に注意が必要だと実感した。 また、処理対象のデータが数万行に及ぶ場合、実行時間の制限に引っかかることもあった。バッチ処理の実装や、処理の段階分けなどの工夫が必要だった。 現在は、辞書データの各処理段階(S02からS06まで)に対応した専用ツールが稼働している。作業効率は以前と比べて格段に向上した。今後はさらなる自動化を進めていく予定だ。

大量の辞書データを扱う上で避けて通れないのが、データの品質管理だ。特に、複数の情報源から集めたデータを統合する際には、重複チェックや内容の妥当性検証が不可欠になる。 当初は人力でExcelシートを見ながらチェックしていたが、データ量が数万件を超えると現実的ではない。そこで、段階的な自動検証システムを構築することにした。 まず、基本的な重複チェックツールを作成した。見出し語の完全一致だけでなく、表記の揺れ(大文字小文字、全角半角など)も考慮する必要がある。また、モンゴル語の場合、格変化した形が重複して登録されていないかも確認する。 次に、分類(CAT)の妥当性チェックだ。これにはGemini APIを活用した。各エントリに対して「この見出し語の分類は妥当か」を判定させ、疑義のあるものにフラグを立てる。ただし、AIの判定が100%正確とは限らないので、最終的には人間が確認する。 さらに高度な検証として、Claudeを使った内容検証も実装した。Google Sheetsからデータを抽出し、GitHub Gist経由でClaudeに渡す仕組みだ。Claudeは語義の説明が適切か、用例が正しいかなどを細かくチェックしてくれる。 この一連のワークフローを「S06データ監査ツール」として統合し、Google Apps Scriptで実装した。ピボットレポート、ファイルリストチェッカー、差分トラッカーなどの機能を持つサイドバーUIとして仕上げた。 完璧なシステムではないが、以前と比べて検証作業の効率は大幅に向上した。人間とAIの協働による品質管理の一例として、他のプロジェクトの参考になれば幸いだ。

辞書データ処理ツール（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の社会言語学パネルにも同じデザインシステムを適用し、プロジェクト全体の視覚的一貫性を完成させる予定だ。