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 Apps Scriptで実装する際、縦書きテキストの折り返し処理に長時間苦労した。最終的に、CSS Columnsレイアウトモデルを使った解決策にたどり着いた。 当初、flexboxを使った実装を試みた。親要素にdisplay: flexとflex-direction: columnを指定し、子要素を縦に並べる方式だ。しかし、これではテキストが折り返される位置を制御できなかった。長いテキストは画面外に突き抜けてしまう。 次に、white-space: nowrapとinline-blockの組み合わせを試した。これはある程度機能したが、複数の記事を表示する際に、記事間の区切りが不明瞭になるという問題があった。 最終的に、CSS Columnsモデルが最も安定していることがわかった。親要素にheightを指定し、column-widthでカラムの幅を制御し、column-fill: autoで自動的に折り返させる。box-sizing: border-boxを併用することで、パディングとボーダーも計算に含められる。 この実装で重要だったのは、記事全体の高さを正確に計算することだった。行数×行の高さ＋パディングで総高さを算出し、それを親要素のheightに設定する。これにより、記事が適切に折り返され、次の記事が正しい位置に表示される。 現在のビューアはシンプル化されたバージョンで、最新の記事のみを表示する。完全版では、記事リスト、追加・編集機能などのUIを統合する必要がある。しかし、核心となるテキスト表示ロジックは完成した。この安定したCSS基盤の上に、残りの機能を構築していく予定だ。

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

辞書プロジェクトのダッシュボードで、各カテゴリのエントリ数を進捗バーで表示する際、線形スケールでは問題があることがわかった。エントリ数が347件の小さなカテゴリと73,225件の大きなカテゴリを同じスケールで表示すると、小さなカテゴリの進捗バーがほとんど見えなくなる。 解決策は、対数スケールの進捗バーを実装することだった。具体的には、3つのキャリブレーションポイントを設定した： このスケールにより、すべてのカテゴリの進捗が視覚的に分かりやすくなった。数百件のカテゴリも数万件のカテゴリも、それぞれ適切な長さのバーで表示される。 実装はMath.log()関数を使用した。まず、最小値と最大値の対数を取り、現在値の対数をその範囲に正規化する。その後、キャリブレーションポイントで調整を加える。 この実装により、ダッシュボードの進捗バーが直感的になった。小さなカテゴリも大きなカテゴリも、それぞれの成長が視覚的に認識できる。線形スケールでは見えなかった違いが、対数スケールでは明確になる。 同時に、タスクステータスバッジのレイアウトも改善した。以前は1行に4つしか収まらなかったが、バッジの幅を狭くすることで1行に5つ収まるようになった。これにより、ダッシュボード全体の情報密度が向上した。

辞書プロジェクトでは、各AIペルソナが定期的に処理すべきタスクリストをGitHubにCSVファイルとして保存している。これらのファイル（Compound Words、News Terms 1-3、Gemini専用タスクなど）を更新するため、ダッシュボードに直接アップロード機能を実装した。 ワークフローは次の通りだ：ドロップダウンから対象ファイルを選択→CSVデータを貼り付け→送信ボタンをクリック。すると、スクリプトがGitHub APIを呼び出し、既存のCSVファイルの先頭に新しいデータを追加する。 技術的に重要なのは、UTF-8エンコーディングの保証だった。モンゴル語（キリル文字）と日本語が混在するCSVデータをGitHubに送信する際、エンコーディングが正しくないと文字化けが発生する。すべてのデータをBase64エンコードしてから送信することで、この問題を回避した。 もう一つの課題は、ヘッダー行の検出ロジックだった。CSVには様々な形式があるが、このプロジェクトでは”MN”,”JP”,”EN”,”CAT”,”NOTE”という引用符付きのヘッダーを使用している。正確にこの形式を検出し、重複してヘッダーが追加されないようにする必要があった。 複数行フィールドの処理も実装した。AIが生成するCSVには、フィールド内に改行が含まれることがある。これを適切にクリーニングし、単一行のCSVエントリに変換する必要がある。正規表現を使って、引用符で囲まれたフィールド内の改行を検出し、スペースに置き換える処理を実装した。 現在、このCSVアップデート機能は安定稼働している。AIペルソナたちは、自分のタスクリストを直接編集することなく、ダッシュボード経由で新しいタスクを追加できる。GitHub APIを通じて行われるため、コミット履歴も適切に記録される。

辞書プロジェクトでは、複数の協力者が異なるツールを使って作業している。一部はGitHubに慣れており、他の人たちはGoogle Driveを使う方が便利だ。そこで、両者を自動的に同期するシステムを構築した。 当初、Zapierを使った簡単な連携を考えていたが、実際には複雑な処理が必要になった。特に、マークダウン形式のログファイルを複数のGoogle Docsに分割して保存し、さらにそれを統合して再びGitHubにプッシュする、という双方向の同期が必要だった。 最終的には、Google Apps Scriptでカスタムスクリプトを作成し、GitHub APIを直接呼び出す方式を採用した。これにより、時間トリガーで自動的にデータが同期されるようになった。 ただし、GitHubの各種APIにはそれぞれ特性がある。コンテンツAPIは更新が速いが、コミットリストAPIには15-60秒の遅延がある。この違いを理解していないと、期待通りの動作にならない。実際、ダッシュボードのバッジ表示がうまく更新されない問題があり、原因究明に時間がかかった。 また、GitHubへのコミット時にはBot用のアカウントを使うことで、誰が更新したかを明確にできる。パーソナルアクセストークン(PAT)の管理には注意が必要だが、適切に設定すれば安全に運用できる。 現在、このシステムは安定稼働しており、作業の継続性が大幅に向上した。複数のプラットフォームをまたいだ協働作業の一つのモデルケースになったのではないかと思う。