エージェントと実行対象① - UnprocessedDocuments

NotesDatabase クラスには UnprocessedDocuments というプロパティがあります。これを使えば「現在実行中のエージェントにとって未処理の文書集合」 を取得することができます。

例えば、

Dim ns As New NotesSession    Dim ndb As NotesDatabase    Dim ndc As NotesDocumentCollection    Set ndb = ns.CurrentDatabase    Set ndc = ndb.UnprocessedDocuments   '未処理の文書の一覧

と記述すると、ndc に未処理の文書の一覧が取得できます。

どの文書が返る？

では、未処理の文書とは具体的にどのように決定されるのでしょうか？実はエージェントのプロパティにある ”対象” により変化します。

「データベースのすべての文書」を選択するとその名称の通りの動作をします。よって、以下の記述はどちらも同じ結果を返すことになります。

Set ndc = ndb.UnprocessedDocuments    Set ndc = ndb.AllDocuments

それ以外の選択肢についての挙動を順にまとめます。

ビューのすべての文書

この設定も名称の通りの動作となります。現在のビューに存在するすべての文書が返されます。

ビューが基準となりますので、文書を開いている状態など、ビュー以外を開いている状態では、エージェントの実行自体がエラーとなります。

ビューのすべての未読文書

この設定もビューを基準とした機能ですので、ビューを開いた状態で実行する必要があります。

ビュー内の未読文書だけを抽出してくれるのですが、ビューの設計で未読文書を表示していなくても構わないようです。こんな設計はわかりにくいだけなのでおすすめはしませんが...

もちろん、データベースのプロパティで「未読マークを使用しない」を設定すると、この機能は動作しなくなります。この場合、UnprocessedDocuments は Count が 0 の空のコレクションを返します。

すべての選択文書

この設定の挙動は３パターンに分かれます。

まず、ビューを表示していて、カーソルで文書を選んだ状態です。この場合は、カーソルのある文書だけが返ります。

同じビューでも、チェックマークを付けて文書を選択している場合は、選択した文書が返ります。この時カーソルのある文書は返されません。例えば以下の例の場合では３文書が返され、「総務部」の文書は含まれません。

ビューではなく文書を開いている場合には、開いている文書１つだけを含むコレクションが返されます。「ビューのすべての文書」や「ビューのすべての未読文書」のようにエラーになりません。

選択肢が「すべての選択文書」となっており”ビューの”といついていない理由なのかもしれませんね。

ただ、ワークスペースでDBアイコンを選択した状態でエージェントを実行すると『選択したエージェントはビューウィンドウから実行してください。』とエラーが出ます。このエラーメッセージにはいただけないですね...。

続きは次回

今回は、エージェントの実行対象と UnprocessedDocuments プロパティの関係についてまとめました。まだ、「作成または変更されたすべての文書」が残っていますが、この設定については次回紹介したいと思います。

ドメイン検索：索引の再作成の注意点

ドメイン検索について注意点をまとめた記事を以前に書かせていただきました。

• ドメイン検索 と 運用上の注意点

その中で、索引の更新には削除文書の反映が含まれないため定期的に索引を再作成することをおススメしました。

今回はその具体的な方法と最新バージョン 14.5.1 で遭遇した新たな現象についてまとめます。

索引を削除するには？

まず、索引の削除のコマンドは load domidx -d です。このコマンドを実行すると索引のフォルダがまるごと消去されます。

次に索引を作成をしようとしたタイミングで、既存の索引が何もないので、対象の全文書を索引するので、再作成となるということですね。

また、索引の削除に関しては下記の技術文書が公開されています。

• ドメイン検索のインデックスを再作成するためには Domino サーバーを再起動する必要がある

2020 年の記事なので現在は改善されているかもしれませんが、再作成前に再起動するほうが良いと考えられます。

サーバ環境や対象の DB 数、文書サイズにもよりますが、索引の再作成には通常長い時間が必要となります。索引作成中は正しい検索結果を得られませんので、業務に影響がないようにするためには、土日などの週末を利用するのがおススメです。

索引の再作成の設定

まず、索引の更新は毎日 7:30、12:00、21:00 の 3 回行う前提とします。

この環境において、土曜日を索引再作成の日として、7:30 の索引作成前に索引を削除します。これで土曜の朝は、索引がない状態で索引を更新しようとするので、すべての索引を再作成することになります。

索引削除の設定はプログラム文書で行います。

プログラム文書を新規で作成し、load domidx -d を実行します。索引作成開始時刻の 30 分前の 7:00、土曜日を指定します。

その後、7:30 の索引作成に間に合うように、サーバを OS ごと再起動させます。

14.5.1 では追加の設定が必要

先日ドメイン検索サーバを 14.5.1 にアップグレードした際、気が付いた問題があります。

14.0 までは load domidx -d の実行だけで索引が削除できていたのですが、14.5.1 では削除されなくなっていたんです（14.5 は未検証なので不明）。調査した結果、14.5.1 では稼働中の domidx タスクを停止しておかないと、load domidx -d が正しく動作してくれないようです。

• 別の domidx プロセスが実行されている場合に「domidx -d」コマンドでドメイン索引を削除できない

これに対応するため、14.5.1 では load domidx -d の実行前（例えば 10 分前）にタスクを停止させます。具体的には以下のプログラム文書を追加することになります。

まとめ

今回は、ドメイン検索の索引再作成の方法についてまとめました。

14.5.1 では少し挙動が違うので注意してください。というか、仕様変更の理由がファイルの共有違反の回避のようなので、過去のバージョンでタスクを停止することなく、索引を削除できたことの方が問題かもしれませんね。

ただ、索引の更新に文書の削除が反映されないことがそもそもの問題だと思うで、早く改善してほしいと思います...。

Notes の強制終了

今回は小ネタを短くお伝えします。

あってほしくはない症状なのですが、Notes クライアントを使っているとハングアップすることがあります。

例えば、以下の画面はロケーションを切り替えようとしただけなのですが、パスワード入力後ワークスペースが表示されることなく、止まってしまいました。はじめは（応答なし）と表示されていなかったので、待たされているのか落ちているのか判断できません。動画を撮ろうと準備している 5 分ぐらいの間に（応答なし）と表示されました。

このような現象が出た場合、皆さんはどのような対応をされていますか？

タスクマネージャから終了

ノーツを一般的な Windows アプリと考えるとタスクマネージャで強制終了させることになります。ただ、この方法は OS から見たアプリの強制終了であり、他の関連タスクやメモリ、テンポラリファイルの削除は期待できないでしょう。再度ノーツを起動した場合、安定したクリーンな状態とは言えないと思います。

デバッグツールの使用

私のような一昔前のノーツユーザが慣れ親しんだ方法です。

ノーツクライアントに同梱されているデバッグツール nsd.exe を利用することで強制終了できます。

手順は次の通りです。

1. コマンドプロンプトを起動する
2. カレントディレクトリをノーツのデータディレクトリに移動（例：c:\Notes\Data）
3. プログラムディレクトリの nsd.exe に オプション -kill を付けて実行

しばらくメッセージが表示された後、最後にファイル名が表示されます。このファイルにはさまざまな情報が含まれており、テクニカルサポートに送付すると原因の調査が行えます。

この方法の利点は、タスクマネージャの強制終了とは違い、ノーツ環境をきれいに掃除してくれることにあります。

WIndows メニューから終了

認知度が意外と低いのがこの方法です。

ノーツをインストールしたマシンには［HCL Applications］というメニューが追加されますが、このメニュー内に「HCL Notes の診断データを収集して HCL Notes を終了する」というものがあります。これを利用すると上記デバッグツールと全く同じことを実行できます。

ちなみに「HCL Notes の診断データを収集して HCL Notes を稼働したままにする」は、その名称の通り、情報収集だけしてノーツの実行を継続します。

まとめ

今回はノーツの強制終了の方法を紹介しました。

ハングアップのような不測の事態以外にも、永久ループの LotusScript を実行した場合や時間のかかる処理を実行したが Ctrl + Break で止められない場合などでも利用できます。

ちなみに、このメニューの認知度が低い理由は Windows の仕様が絡んでいると推察します。例えば Windows 10 では次のように最後まで表示されません。これじゃどっちを選べばいいか判別できず使えないですね。

Windows の仕様もいまいちですが、はみ出るような長い名称を付けたノーツにも非があります。

つないでみよう：#30） Responses API とは？

この連載 つないでみよう は、Web 系アプリ開発ど素人の私が WebAPI 連携にチャレンジする過程をまとめているものです。幅広くさまざまな API に挑戦するつもりだったのですが、最近は OpenAI 社の API ばかりになってきました。WebAPI は種類が豊富で流れが速く OpenAI 分だけですら全然追いつけていないので、その他に手を出す隙はなかなかありません。タイトルを変える必要があるかもしれませんね...

ということで、今回も OpenAI の API がネタとなります。

Responses API とは？

これまでの Chat Completions API の進化版であり、他の API と統合し発展させた新しい標準 API で「今後の新規開発では Responses API を推奨する」と明言しています。

• Migrate to the Responses API

主な特徴としては

• マルチモーダル対応で、テキスト、画像、ファイルを自然に入力
• 会話状態を保持し、前回の応答を継続
• ツール呼び出しを標準化
• 推論モデルとの相性向上

などがあります。

主な対応モデルとしては、

GPT 系	推論モデル（Reasoning Models）
gpt-5 gpt-5-mini gpt-5-nano gpt-5-chat gpt-4.1 gpt-4.1-mini gpt-4o gpt-4o-mini	o3 o3-mini o4-mini

となっていて、新しいモデルほど Responses API の利用が推奨されているようです。

次回からの予定

下記にこの連載で紹介した OpenAI 社の API の機能を整理します。

最初に紹介した通り Responses API は各 API を統合・発展させた仕様なので、これらの操作はすべて Responses API に置き換えることができるそうです。今後、順に移行作業をしながら、使い方や注意点、新機能などをまとめていきたいと思います。

Responses API は新しい標準とのことなので、どんどん使って早く慣れたいですね。

◇ 会話

#1、#2 では、API キーの取得方法など API の基本的な使いから始まり、/chat/completions API を使って AI と会話する方法を紹介しました。送信する JSON に過去の会話を含めることで、会話を継続することができました。

Responses API では、過去の会話を再送することなく、会話を続けることができるようです。

◇ 画像認識

#14 ～ #20  では、/chat/completions の入力に画像を指定することで、画像を説明させたり、OCR のように文字を認識させる方法を紹介しました。

Responses API を使うと、画像認識だけでなく、加工などの編集もできるそうです。

◇ Structured Outputs

AI からの返答を JSON 形式に固定し、指定した構造に合わせて返答させる機能で「構造化出力」と呼ばれています。AI の返答の構造が明確だと再利用が容易なので、プログラムから AI を使用する際には必須の機能と言えます。

#21 ～ #24  では、その指定方法と活用事例を紹介しました。Responses API ももちろん対応しています。

◇ 画像生成

画像生成は /chat/completions ではなく /images/generations という別の API を使用していました。#25 ～ #28 では DALL-E3 を利用した画像生成、#29 では後継バージョン GPT Image API の使い方をまとめしました。

画像生成も Responses API で対応しており、専用のエンドポイントを使うことなく実現できるようです。

前回

連載：つないでみよう

つないでみよう：#29）画像生成 ChatGPT Image

先日と言っても 4 月の初め、OpenAI 社から案内メールがありました。前回までこの連載で紹介していた画像生成 AI の DALL-E3 のサービスが、2026 年 5 月 12 日に終了とあります。今後は最新のフラグシップモデルである GPT Image の利用を検討してほしいとのことです。

しばらくこのあたりのウォッチをサボっていたので、改めて調べたことをまとめておきます。

GPT Image の特徴

旧世代の AI である DALL-E は「画像生成専用モデル」だったのですが、GPT Image はマルチモーダル大規模言語モデル（LLM）との連携を前提にしたモデルで、

• 会話しながら画像を修正
• 画像内容を理解
• 画像編集
• 高度な指示追従

が得意です。単に画像を生成するだけではなく、指示を追加して調整したり、一部分だけ変更したりできるようです。面白そうなのでいずれ挑戦してみたいですね。

GPT Image API の使い方

前回からの流れで、まずは単純な画像生成について確認します。API のヘルプは こちら。

エンドポイントは ”/images/generations” となっていて DALL-E3 と変わりませんね。

そしてサンプルの JSON を確認します。model が "gpt-image-1.5" になっていますが、prompt で作成する画像を指示するなど、構造も同じに見えます。

ちなみにヘルプによると、現時点で指定できるモデルは、

• gpt-image-1
• gpt-image-1-mini
• gpt-image-1.5

の 3 種類の記載があります。そして、この連休中に 2.0 の案内が届きました。すごい勢いで進化しているようですね。

DALL-E3 とは少し違う

どうやら使い方は変わっていないようなので、前回までに作成した DALL-E3 用のサンプルをモデル名だけ変更して実行してみました。すると、次の部分でエラーが発生しました。

レスポンスの JSON が空っぽだったようです。デバッガで確認しても NotesJSONNavigator クラスは中身がほぼ表示されないので、調査しようがありません。

そこで Postman で確認してみるとすぐに原因がわかりました。API ツールって便利ですね。

response_format が unknown_parameter だとエラーが出ています。改めてヘルプを確認すると記載がありました。GPT Image モデルではサポートされていないパラメータだそうです。デフォルトが base64 なので、削除するだけでよさそうです。

同様に quality の設定にも変更がありました。DALL-E3 では "hd" と "standard" が指定できましたが、GPT Image では "high"、"medium"、"low" に変更されており、間違えて指定すると同様のエラーとなります。

モデルによって送信する JSON が変わるんですね。インプリ前に仕様の確認とテストは必須のようです。エンドポイントが同じなので油断してしまいました...。

コードの修正

仕様が明確になったので #26 で作成した関数を GPT Image モデル用に修正します。model と quality にセットする値を修正し、response_format を削除します。

Function xGetJSON(vnd As NotesDocument) As String    Dim jnav As NotesJSONNavigator    Dim s As String    'RequestBody（JSON） の準備    Set jnav = xns.CreateJSONNavigator("")    '1.model    Call jnav.AppendElement("gpt-image-1.5","model")    '1.size    Call jnav.AppendElement("1024x1024","size")    '1.quality    Call jnav.AppendElement("low","quality")    '1.response_format    'Call jnav.AppendElement("b64_json","response_format")    '1.prompt    Call jnav.AppendElement(vnd.Prompt(0),"prompt")    xGetJSON = jnav.Stringify End Function

実行すると無事画像が生成されました。右側は  DALL-E3 で作成した画像なのですが、ずいぶんきれいになっていますね。

まとめ

今回は ChatGPT Image について紹介しました。

旧バージョンの画像生成 API とほぼ同じ仕様となっているのでプログラムはそのまま利用できます。ただ、パラメータの変更など若干の仕様変更がありますので注意しましょう。

前回

連載：つないでみよう

次回

リスト配列の要素数を取得

以前 リスト配列 について紹介しました。

通常の配列は要素を番号で指定しますが、リスト配列は名前などのキーで管理します。例えば、notes.ini のエントリを管理する場合を考えてみましょう。

[Notes] KitType=1 Directory=c:\Lotus\Notes\Data UserInterface=ja InstallType=2 InstallMode=1 NotesProgram=c:\Lotus\Notes\ FaultRecovery_Build=Release 14.5.1 Timezone=-9          ・・・

エントリ数は環境によって違いますし、記述された順番もバラバラです。通常の配列ではすべての要素を順にチェックしないと目的にたどり着けませんが、リスト配列だと一発です。

' asNotesIni は環境変数名をキーにその値を保持している前提     MsgBox asNotesIni("Directory")    'データディレクトを表示

細かな使い方は冒頭のリンクの記事を参照いただきたいのですが、うまく使うとプログラムがシンプルにわかりやすく記述できます。

使用頻度が増えてきて初めて気が付いたことがあります。リスト配列内の要素数を取得できないのです。通常の配列で Ubound に相当する機能ですね。

ざっとヘルプを確認する限り見当たらないので自作しました。

Function ListCount(vasList As Variant) As Integer    Dim i As Integer    i = 0    If IsList(vasList) Then       ' リスト配列の場合件数をカウント       ForAll v In vasList          i = i + 1       End ForAll    End If    ListCount = i End Function

引数で受け取った値がリスト配列か判定し、リストの場合 ForAll でループを回して、件数を数えるだけのシンプルな関数です。

いざ必要となった時に作るのは面倒なので掲載しておきます。

Domino 体力測定：#5）ビュー操作 ⑤ - ハードウェアパフォーマンスとの関係

しばらく間が空いてしまいましたが、これまで４回にわたり GetAllDocumentsByKey と GetAllEntriesByKey の速度比較を行ってきました。検証のテーマは、

	テーマ
#2	一般的な環境（SSD）での基本挙動確認
#3	文書サイズと検索/値取得の特性
#4	ビューの列数と検索/値取得の特性

でした。結果はいずれも GetAllDocumentsByKey が高速であるという結論でした。

連載のきっかけとなった 訂正記事 に挙げたパフォーマンスに影響を与える要因を順番に検証し、GetAllEntriesByKey が早くなるパターンを探してきました。今回は、複数の PC を使用して、CPUやメモリ、ストレージの I/O が与える影響について観察します。

本来であれば別々に観察すべきですが、個人的に用意できるリソースには限りがありますので、おおざっぱなテストになります。予めご了承ください。

検証環境

今回の検証で使用する PC は以下の 3 台で、構成は次の通りです。

	PC1	PC2	PC3
CPU	Ryzen 7 7900X	Ryzen 5 3600	Celeron G540
メモリ	128 GB	32 GB	2 GB
ストレージ	SSD	SSD	HDD
OS	Windows 11	Windows 10	Windows 10

検証に当たり、各 PC のベンチマークを行いました。主な項目と測定結果の画像は次の通りです。

	PC1	PC2	PC3
All	26,123	11,522	756
CPU	17,564	7,065	3842
ランダムリード	713	590	6
ベンチマーク結果

テスト項目と手順

テスト項目はこれまでと同じです。GetAllEntriesByKey では、ビューから値を取得するだけなら 1 ～ 3、文書フィールドにアクセスするなら 1、２、4、5 の合計時間となり、GetAllDocumentsByKey と比較できます。

	検証項目	D）GetAllDocumentsByKey	E）GetAllEntriesByKey
1	コレクション作成	GetAllDocumentsByKey で検索し、コレクションを取得	GetAllEntriesByKey で検索し、コレクションを取得
2	エントリ取得	GetFirstDocument、GetNextDocument で文書を取得	GetFirstEntry、GetNextEntry でエントリを取得
3	値の取得	文書から値を取得	ColumnValues で値を取得
4	文書の取得	－	Document プロパティで文書を取得
5	文書から値の取得	－	文書から値を取得

測定する DB はこれまでのものを流用します。100 Byte のダミーフィールドを 200 個追加した文書（#3 で紹介）を列数の違うビュー（000 と 200）で検索します。000 はダミーフィールドなしの軽いビュー。200 はすべてのダミーフィールドを列に追加した重いビューをイメージしています（#4 で紹介）。

測定手順も同じです。ビューに対して 20 回の検索を行い、取得したコレクションからエントリと値を順に取得する操作を 50 回行います。測定回数は 10 回としますが、PC3 はあまりに遅いため 3 回としました。

結果

測定した結果をグラフに表すと次の通りです。

（図 #5-1）

縦軸をそろえたグラフは次の通りです。

（図 #5-2）

考察

◇ 基本特性の変化

図 #5-1 を確認します。

上段（軽いビュー）の結果を比較すると PC1、2 に比べ PC3 でその差が幾分詰まっています。貧弱なリソース環境においては GetAllEntriesByKey の方が効率的に動くように設計されているのかもしれません。

下段の重いビューでは、処理の比率に変化は見られません。ビューの列が増えることで、効率の良さを打ち消しているのではないかと想定できます。

どちらの検証結果についても GetAllDocumentsByKey が優位であることには変わりがなく、GetAllEntriesByKey が逆転することはありませんし、その気配すら感じません。

◇ リソースの確保は重要

図 #5-2 では縦軸をそろえているので、絶対的なレスポンスがわかります。

最も時間を要している処理１を使って比較します。PC1 の処理時間を基準にすると次のような差（単位：倍）となりました。

環境	View = 000	View = 200
PC2	2.48	2.30
PC3	11.58	64.77

PC3 ではストレージが HDD であることに加え、CPU やメモリも貧弱です。これが原因で、テスト時にはスラッシングが発生していたと推察できます。これが原因となり PC2 に比べ異常ともいえるパフォーマンスの劣化が発生したと考えられます。リソース確保の重要性がよくわかる結果ですね。

まとめと今後の進め方

PC3 の View = 200 のテストはスラッシングが発生し、スペック以上に能力が低下していたと推察しました。ということは、さらに昔の世代のテストができたのかもしれません。しかし、この状況においても GetAllDocumentsByKey が優位であることには変わりがありませんでした。本当に昔の常識とされた GetAllEntriesByKey 優位というシナリオは存在するのでしょうか？

残された可能性は ODS ぐらいですかね。最近の ODS では GetAllDocumentsByKey に対する最適化が進み、逆転するシナリオが存在しないという可能性です。ODS については腰を据えて、検証してみたいと思っていたので、別途検証したいと思います。よい結果が出れば、塩漬けされた Domino サーバをバージョンアップする理由になるかもしれませんね。

これまでの『Domino 体力測定』は、きっかけとなった 過去の神話 を検証する方向で進めてきました。明確な答えが出ないまま方向転換するのは残念なのですが、過去を振り返るより将来にわたって ”使える” 検証に時間を割きたいと思います。

今後 ODS の評価以外にも、NotesDocumentCollection クラスの GetNextDocument と GetNthDocument の比較など、複数の手法がある開発を題材に比較してみたいと思います。

前回

Domino 体力測定

Notes 14.5.1 とデフォルトフォント

Notes 14.5.1 ではデフォルトフォントが Inter 系に変更されました。このフォントはシンプルでモダン、英数字のバランスが良く、特に画面表示において読みやすいフォントだそうです。

設定画面とデフォルトフォント

Notes クライアントのファイルメニューから［設定］を選択します。

14.5.1 ではこのメニューが階層表示するよう改善されています。ちょっとスペースを取りすぎているような気もしますが、わかりやすくなっています。また、検索もできるようになったのもよさそうですね。

デフォルトフォントの設定は［クライアントの構成］－［Notes クライアントの基本設定］にあります。

［デフォルトフォント］ボタンで確認すると Default Sans Serif が Inter Medium となっています。この設定で Notes 内のすべてのアプリを一気にモダンにしようという算段のようですね。

この設定でアプリを使用していて、いくつか気が付いたことがあります。

￥マークの表示

最初に気が付いたのは、半角の ￥ がバックスラッシュ（＼）として表示されることです。

フォルダの区切り文字が変わる程度であれば問題はありませんが、金額に￥マークを付けているような通常の文書では気になると思います。

折り返し注意

Inter 系のフォントはこれまでのフォントより幅広となります。これがきっかけとなり、折り返しが発生したり、日付と時刻がひっついて表示される現象が出ました。

フォームの設計を確認すると、日付と時刻をそれぞれ表のセルに入れる仕組みになっていました。列幅を固定することで隙間を開けていたのですが、フォントの幅が変わることで想定外の状況になったようです。

このような現象はノーツの文書でも発生します。

リッチテキスト内の表では［自動サイズ]が利用でき、その時点のセル内の文字に合わせて表の幅をピッタリに合わせてくれる機能があります。

旧バージョンでこの設定を実行し 14.5.1 で確認すると、折り返しが発生してしまいます。

まとめ

今回は 14.5.1 のデフォルトフォント変更について、気が付いた点を紹介しました。フォント系のトラブルとしてはよくある話ですね。

見た目を一気にモダンにできる反面、今回のように多少の影響も発生します。対策として「旧来フォントに戻す」という手もあります。確かに安心で手軽です。また、フォーム設計で Default Sans Serif を使わず、「メイリオ」などに固定する方法もあります。

そんなことを考えていたら、ふと思い出したセリフがあります。

『地球の重力に魂を引かれた人々』

これら対策は最適解なのか、それとも“慣れ”に引かれているだけなのか。さて、あなたはどちらを選びますか？

ニュータイプになるには、試練を乗り越える必要がありそうです。

Notes 14.5.1 の絵文字の仕組み

先日リリースされた Notes 14.5.1 の新機能の中に絵文字のサポートがあったので、試しに触ってみました（Notes 14.5.1 の一般的な機能強化）。

絵文字の使い方

Notes 14.5.1 ではリッチテキストエディタの拡張として絵文字をサポートしています。ツールバーのフォントのエリアに絵文字を入力するための機能が追加されています。

実際にメールを新規作成して、入力してみます。

ツールバーから絵文字を選択するとカーソルのある所に挿入されます。使い方は他のアプリと同じですね。

実際にメールを送信して、Gmail で確認すると Notes と全く同じように表示されています。

絵文字の仕組み

どのように実現されているのか仕組みを確認します。

Notes で送信したメールを開き文書のプロパティで確認します。残念ながら、絵文字らしき情報は確認できないですね。

詳細を調べようと思い、リッチテキストを DXL に変換して確認するとすぐにわかりました。絵文字はただの画像なんですね。リッチテキスト内に直接貼り付けたインラインイメージと同じ構造になっています。

DXL について興味のある方は別の連載『DXL ことはじめ』『DXL Step-by-Step』を参照ください。

Notes らしい実装

画像だとわかれば DXL を使わず、もっと簡単に確認できます。絵文字を選択してプロパティを開くと［画像］として表示され、インラインイメージとして表示されます。

”絵文字”って言うので、Unicode で定義されている絵文字を想定していましたが、今回の対応では画像としての対応でした。

文字 vs 画像。文字は、軽量で検索も可能な反面、フォントなど環境に依存します。画像は、環境依存が少ない反面、データサイズが大きくなります。どちらも一長一短あります。

Notes/Domino は過去のバージョンとの互換性を重視しているシステムです。今回実装の画像での対応は、以前からある機能そのまま利用しているだけですから、過去のバージョンの Notes クライアントでも問題なく表示できます。

Notes/Domino らしい実装だと言えますね。

複数値を分離して表示とヘッダーソート

以前『リスト値とビュー』という記事で、Notes の特徴的な機能であるリスト値（複数値）をビューで活用するテクニックを紹介しました。先日、このテクニックに関して新しい注意点を発見したので紹介します。

複数値を分離して表示の動作

まずは、前回の記事を再編集して、そのテクニックのおさらいします。以下のフォームは交通費精算書をイメージしています。交通機関や金額は１申請につき複数必要となりますが、これをリスト値で管理させています。

このような構造とすることでフィールド数が削減でき、入力できる件数に実質制限がなくなります。Notes ではよく使う手段ですよね。

紹介したテクニックは、このような複数のリスト値が対になって保存されている文書をビューでバラバラに表示する方法です。利用するのは列のプロパティにある『複数値を別のエントリで表示』です。

例えば、交通機関でカテゴリ化して、金額と備考を『複数値を別のエントリで表示』させると次のようになります。リスト値の各要素がうまく分離されて表示できます。

なお、この『複数値を別のエントリで表示』機能は少々癖のある制限があります。前回の記事では、次の２つを紹介しました。

• 『複数値を別のエントリで表示』する列より左の列でソートする
• 『複数値を別のエントリで表示』する列ではソートできない

例えば、金額列でソートも有効にします。すると、次のようにすべての組み合わせがビューに表示されるという症状が出ます。今回の文書で言うと青が正しい行で、赤が正しくない行となります。

今回発見した現象

前置きが長くなりましたが、ここまでは復習で、ここからが今回の本題です。

リスト値を活用したアプリ開発において、私はこの技をよく使用するのですが、まれに思い通りに動かないことがありました。ずっと原因不明だったのですが、先日理由がわかったので紹介します。

発生した問題は次の通りです。一見、リスト値がうまく分離されているように見えるのですが、各行で本来異なるはずの金額が、すべて「リストの1件目の値」で上書きされたような表示になっています。

この現象は、先に挙げたすべての組み合わせが表示される症状とは違います...。

原因

このビュー、以前は正常に動作していたんです。ただ、ある時ユーザの要望でちょっとだけ修正したタイミングから正しく動作しなくなりました。

間違い探しみたいですが、先の画像の修正前後を見比べるとその原因がわかります。

そうです。原因は、ビューヘッダーのソート機能を有効にしたからなんです。

実際にそのカラムでソートしてみると次のようになります。ソートしたときに表示されている値が、ヘッダーソートをしない状態でも採用されており、しかも、すべてのリストエントリで表示されるという現象が発生していたようです。

まとめ

今回は『複数値を別のエントリで表示』機能で新たに発見した現象を紹介しました。うまく動作すれば便利に使える機能ですが、落とし穴がいくつもあるので注意が必要です。

きっかけとなったヘッダーソートの機能は、便利でユーザ受けもいいので、安請け合いしがちなのですが、思わぬ影響が出てクレームにつながりました。おいしい話には裏がある、慎重に行動しないと駄目ですね...