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件目の値」で上書きされたような表示になっています。

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

原因

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

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

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

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

まとめ

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

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

それ、バグじゃなくて“索引”です

先日、ユーザさんからの調査依頼がありました。「ビューに表示されている値と、文書を開いたときの値が違う」というのです。若手担当者にはバグに見えたのでしょう。懸命に調査していました。

しばらくたって、相談を受けたのですが、私のような ”古参 Notes オタ” ならピンときます。なんだかわかりますか？

そうです。「ビューの索引が壊れた」ってやつですね！

そういえば最近の Notes/Domino ではあまり発生しなくなったような気がします。ずいぶん性能が上がって、安定したんでしょうね。私がノーツを始めた 30 年前はよくありました。だからこそ、察しがつくんです。

本当に壊れてる？確認してみよう

私がよく使うビュー索引のチェック方法を紹介します。

対象のビューを Domino Designer で開き、F9 を押し、ビューの中身を表示させます。Designer 上に表示された中身と Notes クライアント上のビューを比較します。差がある場合には索引が壊れている可能性が高いです。

索引の再構築（Shift + F9）

ビュー索引の再構築は Notes クライアントから簡単に行えます。対象のビューを開き、Shift + 'F9' キーを押すだけです。ステータスバーに『索引を再構築します...』とメッセージが表示され、終了すると再構築したビューが表示されます。文書数が多い DB では時間がかかることもあるので注意しましょう。

昔の Notes では、メールでこの操作を行うことがありました。ノーツ利用歴が長い人ほどこの操作になじみがあるのはこのためですね。

ちなみに、Shift をおさない F9 はビューの更新だけなので、索引は再構築されません。

他にもある再構築方法

ビュー索引の再構築は他にもいろいろな手段があります。例えば、

1. ビューの設計を変更する
2. サーバコマンド updall -R を使う
3. Administrator クライアントの［ファイル］タブで、［データベース］－［ビューの管理...］がらビューの索引を消す

 などです。

1 と 3 の操作では索引が消えたままとなるので、次にユーザが開いたタイミングで索引が構築されます。DB が大きい場合、最初のユーザが割を食うことになります。もはや、管理者による無差別テロです。...なので、ちゃんと索引は作っておいてあげましょう。

Notes/Domino 2026 (v14.5.1) がリリースされました！

2026/3/19 の夕方（日本時間）、Notes/Domino の最新バージョンがリリースされました。ところどころで ”2026” と表記されていますが、バージョン番号でいうと 14.5.1 となります。早速インストールしてみました。

今回は Notes クライアントのファーストインプレッションを紹介します。

Notes クライアントを起動すると、いつも通りパスワード入力画面が表示されます。マージンを広くとった今風の画面に変更されていますね。入力したパスワードに応じてアイコンが切り替わる伝統的な機能はそのままなので、オールドタイプなユーザにもなじめるように配慮されているのがありがたいです(笑)。

最初に表示される画面に Notes 2026（v14.5.1）の新機能がまとめて紹介されていますね。

プロパティボックスの変更

私が一番インパクトのあると感じたのは、プロパティボックスの変更です。これまでの Notes クライアントでは小さなポップアップ画面に表示されていましたが、14.5.1 ではサイドバーに統合されています。

文書を選択して Alt + Enter でプロパティボックスを開こうとすると、サイドバーが開きそこにプロパティが表示されます。旧文書プロパティ画面の上部にあったタブは、アコーディオン形式のインターフェースに変更されています。サイドバーアプリらしい仕様変更ですね。

サイドバーのプロパティアプリ（呼び方が正しいかは不明）の最上部にはオブジェクトを切り替えるコンボボックスがあり、『データベース』のプロパティに切り替えることができます。基本的な機能は旧来のプロパティボックスを踏襲しているので、操作に迷うことはなさそうです。

旧来のフロート型では Windows で 150% などに拡大した場合や 2 画面以上のディスプレイを使用すると、プロパティボックスが行方不明になることがあったので、この仕様だと安心ですね。

サイドバープロパティはマージンを十分にとった今風の画面に仕上がっています。マウスの移動距離が少し長いこと、見た目が Excel ぽいのが少し気になりますが、正しく進化しているということなのでしょうね。

なお、右クリックメニューの一番上から［プロパティ］が消えていて、プロパティとしては詳細プロパティが採用されいます。プロパティボックスを開く操作で右クリックメニューを利用していた方は注意が必要ですね。なお、初めにも書きましたが、Alt + Enter の操作でプロパティを開く操作は引き続き有効です。

文字のプロパティは便利

サイドバーに入ったプロパティで大きく変わったのは『文字』の設定です。特に色の設定は他のアプリでも一般的にありそうなインターフェースになっています。マウス操作でフルカラーから選択できますし、16進数で色コードを入力することもできます。

秀逸だと感じたのはスポイト機能です。これを使えば色番号がわからなくても同じ色に設定することが可能になります。

このスポイト機能は、Notes クライアントの外側、Windows の他のアプリからも色を拝借できるのでとても便利そうです。

ポップアップ表示される”点眼器”って日本語訳はいただけないですが...。

がんばれ Designer！

さて、今回はインストールほやほやの Notes 2026（v14.5.1）を紹介しました。いろいろ書きたかったのですが、結果的にプロパティボックスの話だけになってしまいました。その他の機能については、おいおい紹介したいと思います。

ところで、このサイドバーのプロパティボックスは、残念ながら Notes クライアントのみで有効です。残念なことに Designer では利用できず従来通りのフロート型のボックスで表示されます。プロパティの複雑度がはるかに高いことや UI の構造が違うのが原因でしょうが、統一してほしいですね。

しかも、Designer をインストールしたマシンの Notes クライアントでも使用できないんです。ということは私にとっては縁のない機能ってことになります。スポイト機能は開発者こそ必要な機能だと思うんですけどね。

早急な対応を希望します。がんばれ！HCL の”中の人” !!