Latest topics 近況報告

Virtual DOMでなく生のDocumentFragmentを与えてDOMを差分更新したいって話 - Mar 09, 2020

この記事はQiitaとのクロスポストです。

概要

FirefoxのアドオンやChromeの拡張機能向けに、名前空間をまたいでDOMに変更を差分適用したい場面で使える、Virtual DOMでないReal DOMで差分適用する、webextensions-lib-dom-updaterという名前のライブラリをつくりました。

• リポジトリ
• npmモジュールの公開ページ

どう使うの？

クライアント側でタブの情報を取得して、サーバー側でそれをレンダリングする、という場面であれば以下のようになります。

クライアント側（制御担当）：

// IDからタブのオブジェクトを得る（WebExtensionsのAPI）
const tab = await browser.tabs.get(tabId);
// プロセスをまたいで、レンダリングして欲しい内容を送る
browser.runtime.sendMessage(
  '受信側の識別子',
  // ↓テンプレート記法でHTMLのコード片をそのまま生成
  `
    <span id="tab"
          class="${tab.active ? 'active' : ''}">
      <span id="throbber"
            class="${tab.status}">
        <span id="throbber-image"
              class="${tab.status}"></span>
      </span>
      <img id="favicon"
           class="${tab.status}"
           src="${tab.favIconUrl}">
      <span id="label">${tab.title}</span>
    </span>
  `.trim()
);

サーバー側（画面描画担当）：

import { DOMUpdater } = './dom-updater.js';

// 他のプロセスからのメッセージを待ち受ける（WebExtensionsのAPI）
browser.runtime.onMessageExternal(message => {
  // 反映先の要素
  const before = document.getElementById('container');

  // 反映する内容をDocumentFragmentにする
  const range = document.createRange();
  range.setStart(document.body, 0);
  const after = range.createContextualFragment(message);
  range.detach();

  // DocumentFragmentの内容でbeforeと異なる部分があれば、
  // それをbeforeに差分適用する
  DOMUpdater.update(before, after); // ←これを作った。
});

どの辺に新規性があるの？

Virtual DOMでなく生のReal DOMを更新内容として指定する（※例ではDocumentFragmentを使ってますが、普通のElementでも構いません。）ので、Virtual DOMの独自記法を覚えなくていいです。利点はそれだけです。

既に同じ事をするライブラリが世の中にはあったのかもしれませんが、自分には見つけられませんでした。どなたかご存じでしたら教えてください……

→と書いていたら、morphdomという似た趣旨のライブラリが既にあると教えて頂きました。今回実装したものとの比較を最後に追記しました。

なんで作ったの？

Tree Style TabというFirefox用アドオンで、「他のアドオンから指示して、タブの中に任意のUI要素を追加する」という事をやるために作りました。

見た目を元々のタブに合わせているのでちょっと分かりにくいですが、このスクリーンショットの左側で「Add-ons - Mozilla | MDN」というラベルを伴って表示されている「細いタブっぽい物」が、別のアドオンから指示された通りの内容を、このライブラリによる差分適用で埋め込んだ部分です。

アドオン間での通信ではJSONオブジェクト形式のメッセージしか扱えないため、こういう事をやろうとすると

• 挿入するUI要素の内容を、どんな書式でどうやって指定させるか
• 挿入されたUI要素を、どんな書式でどうやって指定して更新させるか

ということを決める必要があります。

Virtual DOM使えばいいやん

DOMの変更の差分適用といえば既存のVirtual DOM専用のライブラリは既にいくつもあって、

• https://github.com/Matt-Esch/virtual-dom/
• https://github.com/snabbdom/snabbdom
• https://github.com/yelouafi/petit-dom

このあたりの記法をそのまま使えばいいといえばいい話です。

が、どれもべつに「スタンダード」というわけではないようなので、どれを選んでも後で文句を言われそうな気がします。宗教戦争がもしあるなら、そこに参戦したくはないですし、ただでさえ「Tree Style Tabが他のアドオン向けに提供する独自のAPI」というめちゃめちゃニッチな場面なので、こんな限定された場面のために新たに（もし普段から使っている物があるなら、それとは別のライブラリ由来の）独自の記法を覚えてもらうのは忍びないです。というか、自分がこれ以上覚えたくありません。

その点、HTMLのソースを文字列で指定してDOMの標準的な機能でNodeやDocumentFragmentにするという事にしておけば、多少冗長ではあるものの、「デジュールスタンダードなんで」と言ってしまえます。技術選択で悩まなくてもよくするためだけの選択というわけです。

続きを表示する ...

安眠を手に入れるために工作と裁縫した - Jan 05, 2020

うちは大きなベッドを1つ使うのではなくシングルサイズのベッドを2つ並べて使っているのですが、引っ越しを機にベッドを買い換えたら困った事になり、工作と裁縫で解決しました。という話です。

続きを表示する ...

「社員名簿」のダミーデータをシェル（とFaker）で作る - Dec 17, 2019

このエントリはQiitaとのクロスポストです。

シェル芸アドベントカレンダー2019に空きがあったので、最近やったシェルの話で参加させていただきます。

自分は日経Linux誌でシス管系女子というシェルの解説記事（マンガ）を連載させていただいてます。その2020年1月号掲載分の回において、「劇中の架空の会社で、アダムズ方式を使って各部署から代表者を何名かずつランダム且つ公平な感じで選ぶシェルスクリプトを作る」という話をやっています。

アダムズ方式では、前の計算の結果を使って次の計算を行うというステップが何度か出てきます。今までは「1画面分だけの画面出力」が必要なケースが多かったので都度てきとうにその場の気分で偽の画面をデッチ上げていたものの、こう複雑な話になってくると、それぞれの画面間で数字に矛盾が無いようデッチ上げるのはなかなか大変です。なので、実際にそれっぽい「社員名簿」のダミーデータのCSVを作って、その処理結果をそのまま使うことにしました。

こういう場面でのダミーデータの作り方はいろいろあると思いますが、描いているのがシェルの解説なので、シェルでやってみました。というのがこの記事の内容です。

続きを表示する ...

僕がある問題について自分がどう考えるかとその背景を書いているのは、フルブレーキングの副産物に過ぎない、という話 - Dec 08, 2019

blogとの付き合い方について あるいはなぜ自分がblogを書き続けているかについて - podhmo's diaryという記事の中で、僕の事が以下のように評されてました。

Piro_orさんはある問題について自分はこう考えるということの表明とその背景説明がとても上手な印象です。

これを書かれた方ご自身は「自分の思った事を書く」という事が今あまりできていないそうで、それで「できている人」として例に挙げて下さっていて、尊敬しているとまでおっしゃって頂いていてなんというか恐縮です。確かに、自分でもそういう事をよくしているような気がしてます。

ただ、自分がそうしている事の動機がどこにあるのかという事を改めて考えてみると、必ずしも目指すに値する対象とは言えないんじゃないだろうかという気がしています。

続きを表示する ...

技術解説マンガをやるならこんなふうに（書き手と編み手の Advent Calendar 2019） - Dec 05, 2019

タイトルは服を着るならこんなふうにのパクリです。

書き手と編み手の Advent Calendar 2019をご覧の皆様、初めまして。ライターとしてプログラミングやなんかのIT解説記事を執筆する事がある、Piroと申します。ライター・編集者向けのアドベントカレンダーなのに、何故マンガ？と思った方向けに、最初にちょっと背景を説明したいと思います。

自分はUnix系環境のシェルのコマンド操作やシェルスクリプトをマンガで解説するという連載記事を、シス管系女子というタイトルで日経Linux誌にて2011年から描いています。導入の1～2ページだけマンガという形式ではなく、毎回6ページのマンガだけで解説するという形式で、原作から作画まで1人での制作です。実際の内容は日経xTECHでより抜きエピソードが公開されていますので、そちらを見て頂くと「ああ、こういうやつね」とお分かり頂けるかと思います。

このエントリでは、こういうガッツリ系解説マンガを作るにあたっての

• 普通の文字原稿の技術解説記事とどう違うか？
• 普通の（技術解説ではない）マンガとどう違うか？

を語ってみます。というか、そういう点を深く意識しないままに描き始めて後から「ああ、あのときこうしておけば良かったのに」と後悔したことが色々あり、それを振り返ってまとめてみたという感じです。

「自媒体にマンガ形式の記事を載せたい・マンガ形式の解説書を出したいが、マンガのことはよく分からない」という編集者の方や、「マンガで解説を書くことになったがどう書けばいいか分からない」という原作・作画の方の参考になれば幸いです。

続きを表示する ...

言葉が通じない同士で対話するのが面白い「ヘテロゲニア リンギスティコ」、言葉は通じるのに対話ができないのが辛い「魚頭さんと袋さん」 - Oct 31, 2019

最近ニコニコ静画の通知で流れてきた漫画、当初はよくある異世界物かぁ～と思ってあまり食指が動かなかったんだけど、なんとなく読んでみた。そしたら謎の感動を覚えて、それどころか泣きたいような気持ちになってしまって、既刊の電子書籍も全部ぽちって、さらにその気持ちが強まるという体験をした。べつに「泣ける話」ではないはずなんだけど、泣けてくる。何故なのか。

その漫画のタイトルは「ヘテロゲニア リンギスティコ ～異種族言語学入門～」（作：瀬野反人）。現代人で言語学者のハカバ君（劇中ではもっぱら「センセイ」と呼ばれる）が、師事する教授の代理として「魔界」に赴いて現地でフィールドワークをする中で遭遇する、様々な出来事を描く作品だ。内容やテーマが似た作品としては、

• ファンタジー世界で異種族の文化に時々言及する描写のある「ダンジョン飯」（作：九井諒子）
• 実在の人物の旅行記を下敷きにして「西洋人から見た開国直後の日本」を異世界として描く「ふしぎの国のバード」（作：佐々大河）

などが該当するだろうか。

続きを表示する ...

誤用の心理的安全性 - Jul 10, 2019

いやね、「みんな仲良くぬるま湯状態」は心理的安全性とは違うとはみなさん言いますけど、それじゃあ「口の悪いベテランが欠点をあげつらって罵倒しまくってて、それに新人がビビってる状態」は心理的安全性があるのかないのか、って話なんですよ。

最近「心理的安全性」という言葉をよく目にします。

最近あった7payのトラブルは、パスワード再発行の仕様がザルで、誕生日とメールアドレスさえ分かれば第三者がアカウントを乗っ取り放題だったせいで、最低でも900人に計5500万円以上の被害が出た上に個人情報も漏洩した恐れがある、という事件でした。以前から一般ユーザーによって危険性が指摘されていたという話も、開発に関わった人が良識を持っていれば絶対に指摘していただろうという話も聞かれて、そういった技術的・倫理的に正しい指摘がきちんとエスカレーションされていさえすれば防げたかもしれない事件だった、なのに誰も止められなかった。何か言えば上司に「余計な事を言って仕事を増やすな」とか「スケジュールを遅延させる気か」と詰られると思うと、皆我が身かわいさに「正しい指摘」を引っ込めざるを得なかった、のではないだろうか。正しい事を正しいと言えなかったがために起こった事故なのだろう。……というような話がまことしやかに囁かれています。

そういう事を防ぐために、正しい事を正しい・間違っている事を間違っているときちんと指摘してよい、指摘しても懲罰的人事などの理不尽な形で不利益を被る事は無いという意識が、メンバー全員で共有されている状態。挑戦に失敗しても致命的なダメージを被らないで済むというセーフティーネットがあるために、意欲的に挑戦してより良い成果を生み出せる状態。みんなで一丸となって、やるべき事をつつがなく遂行できる状態。そういうのを、心理的安全性が高い状態と言うそうです。

詳しい話は心理的安全性ガイドライン（あるいは権威勾配に関する一考察）とかそのあたりの記事を参照してください。

その「心理的安全性」なんですが、急激に流行りだしてバズワードと化したせいか、本来の意味とは異なる意味で使われてしまっている場面があるそうです。具体的には、「批判されると萎縮してしまって何もできなくなる。だから、相手の事を批判してはいけない。みんな仲良く、和気藹々。それが心理的安全性が高い状態である」というような使われ方。

先の説明から続けて読めば、これがどうして「間違った理解」なのかは明白ですよね。「本来の心理的安全性」は筋の通った正しい指摘を引き出す物のはずなのに、「誤用の心理的安全性」では、そういう正論ベースの指摘は「和を乱す物」として否定され得る。明らかな穴があっても、「彼がせっかく頑張って考えたプランなんだから、それでやろうよ」と、穴に目を瞑ってナアナアで済ませる。そうして幾つもの誤りを見過ごして破滅に突き進む。我々はこれを言い表す的確な言葉を既に知っています。「事なかれ主義」です。その単純な言い換え語として「心理的安全性」を使うというのは、確かにいただけません。

でもその一方で、この誤用をしたくなる気持ちを僕は否定もしきれないんですよね。何故なら世の中には、「論理的に正しいかどうかがすべて」を信条に、人の神経を逆撫でしたりこき下ろしたりする人がいるからです。ただの観測範囲の問題かも知れないんですけど、「（IT）エンジニア」にはそういう人が目立つような印象が、僕にはあります。

続きを表示する ...

Information disclosure vulnerability of Tree Style Tab and Multiple Tab Handler - May 29, 2019

日本語版

As already announced at changelogs, an information disclosure vulnerability was found in Tree Style Tab 2.0-3.0.13 and Multiple Tab Handler 2.0-3.0.6.

• The vulnerability was already fixed at TST 3.0.14 and MTH 3.0.7.
• Please be careful if you deactivated auto-update of addons, or using old TST or MTH on old Firefox. I strongly recommend you to update or uninstall them for safety.

Technically detailed description is already published at a GitHub issue. It was a spec bug around APIs for communication with other addons. In short: the API design was not matched to the security model of WebExtensions API itself.

• A WebExtensions based Firefox addon can read privacy data of tabs, only when such a risk was notified on its installation and you intentionally granted that. Title, URL, and "FavIcon" of tabs are such sensitive data.
• TST and MTH are addons providing list-like UI for tabs, so they must require permissions to access such sensitive tab data. You might saw such notification on your initial installation.
• TST and MTH provide API for other addons to notify information of specified tree or multiselected tabs. The data notified via those API were constructed from tabs.Tab objects got via WebExtensions API with their own permissions, and they contained full tab data from both regular and private windows, including title, URL, and FavIcon, without any confirmation. To be honest, I forgot that those properties are not accessible without tabs which is a non-default permission.
• Their API is callable via a general WebExtensions API browser.runtime.sendMessage(), and any addon can call browser.runtime.sendMessage() with no special permission.
• As the result, sensitive tab data were accessible from any other addon with no permission and no warning when TST or MTH was installed.

Currently there is no report about actual such an "attacker" addon. This vulnerability was found by a self-check.

However, it existed for a long time (from initial releases of their versions 2.0 at 2017), and might be known axiomatically with public API documents - attackers might find it out when he read the API spec carefully. If you found any actual attacker example, please tell them me.

I already contacted to community managers of Mozilla, so I will update this announcement if any progress.

Why I did such a terrible mistake? I think there are mainly two reasons.

First, TST and MTH were originally developed as XUL addons.

In old days, all XUL addons had same permissions: they were allowed to access any data on Firefox. Old API of these addons were also designed on the policy same to XUL addons themselves - there was no concept like permissions for each client addon.

On the other hand, there are some known concepts of WebExtensions: isolated namespaces and secure permission model based on declarations. So users just need to be careful about safety for each addon simply. And, there is one more self-evident (but I missed that) fact: my addons TST and MTH may be allowed to read sensitive data, but other API client addon may not.

This means that it was required that updating the concept of my APIs following to the security model of WebExtensions API itself. But regrettably I forgot to do that - I concentrated to migration of their features and missed this point. As the result, TST and MTH were became like a bigmouth: they got sensitive information out of Firefox and blabbed to others carelessly.

Second, I misunderstood the power of the tabs permission.

The permission name tabs looks like required to do anything around tabs, for example getting a list of tabs. So, because APIs of TST and MTH require id of tabs as their parameter, I thought that "client" addons must have the tabs permission and there was no problem to return full tab information.

But that was misunderstanding. Actually, many WebExtensions API around tabs are callable regardless the addon has no tabs permission, and the permission just appends extra sensitive properties to tab objects. I added tabs to required permissions on very early days of my WebExtensions addon development experience and it was left there for a long time, thus I had no chance to correct such a misunderstanding. Possibly I might specify tabs permission for other addons even if it is unnecessary.

Please remind my mistake as a lesson, if you plan to design callable API for other addons. You need to be careful to treat any data got via WebExtensions API as sensitive, as:

• You should understand the exact effect of the permission you specified at permissions in manifest.json. Don't put needless permissions, and keep it mind that you should make effort to minimize the list of permissions anytime.
• You should build response/notification messages for other addons from scratch, especially without recycling of objects got via WebExtensions API with your own permissions.

ツリー型タブとマルチプルタブハンドラに脆弱性がありました - May 29, 2019

English Version

既にTwitter等でお知らせしていますが、ツリー型タブのバージョン2.0～3.0.13とマルチプルタブハンドラのバージョン2.0～3.0.6に脆弱性がありました。

• 問題自体はツリー型タブ 3.0.14以降およびマルチプルタブハンドラ 3.0.7以降で修正済みです。
• 自動更新を停止していたり、古いバージョンのFirefox用に古いTST・MTHを使用していたりすると、脆弱性を突かれる恐れがあります。更新またはアンインストールを強くお勧めします。

詳細な説明はGitHubのissueに日本語でも記載していますが、端的に言うと「他のアドオンと連携するために独自に提供していたAPIの仕様がガバガバだった」という事になります。

• 通常、WebExtensionsベースのアドオンでは明示的に宣言されインストール時に許可された範囲の情報しか取得できない。タブの現在のタイトル、URL、アイコンもそのような情報の一種。
• TSTやMTHは動作上どうしてもタブのタイトルやアイコンを知らなくてはいけないので、それらの権限を要求する旨宣言している。インストール時にもそのあたりの事が警告される。
• TSTやMTHは、他のアドオンの求めに応じてツリーの情報や選択されたタブの情報を返したりプッシュ式に通知したりするためのAPIを提供している。このAPIを介して返される情報は、TSTやMTHが自身の権限に基づいてWebExtensions APIから得たtabs.Tabのオブジェクトに基づいて、それとの互換性を保つようにしていたため、その中に無条件でタブのタイトル、URL、アイコン、およびプライベートウィンドウのタブの情報が含まれていた。これらの情報が、本来は取得するために特別な権限が必要な物であるという事を失念していた。
• このAPIはbrowser.runtime.sendMessage()というWebExtensions APIを使って呼び出す物だが、browser.runtime.sendMessage()の呼び出しには特別な権限は要らない。
• よって、TSTやMTHがインストールされている環境では、どんな権限でインストールされたアドオンからでも、全く無警告に、そういった情報を参照できてしまうという状態だった。

一応、この「脆弱性」を使って悪さをするアドオンとしてこういう物が実際にある、というような報告はまだ受けていません。あくまで、作者が自主的に行った仕様の再チェックで脆弱性が見つかったという事になります。

が、「誰も気付かないような所、仕様の穴を突いたイリーガルな使い方をすると情報を盗み出せる」というような物ではなく、技術情報としてドキュメントも公開しているAPIを堂々と使って、WebExtensionsのアドオンごとの制限を突破して情報を取得できる、しかもその情報自体は実は2017年のバージョン2.0リリースの時から1年半以上もの間ずっと公知だったという、我ながら書いていて情けなくなるお粗末な状況なので、この脆弱性を利用した悪意あるアドオンが既に存在していても、全くおかしくはないと思っています。

ということで、もしそのようなアドオンを見つけた方がいらっしゃいましたら、お手数ですがどうかタレコミをお願いします。

折良く（？）、Mozillaのアドオンコミュニティの担当者の方からおすすめアドオンの件について連絡を頂いたので、ついでにこの件についても相談してみました。何か進展があったらまた告知すると思います。

それにしても、何故こんなにお粗末な事をやらかしてしまったのか。理由はいくつか考えられます。

まず1つは、XULアドオン時代の設計思想を引きずってしまっていたこと。

元々、XULアドオン時代にはFirefoxのアドオンはすべての情報にフルアクセスというのが当たり前でした。なので、TSTやMTHのAPIには、呼び出し元ごとに返す情報に差を付けないといけないという考えが全くありませんでした。聞かれた事はなんでも返していい、何故ならどうせ呼び出し元のアドオンだって、それらにアクセスしようと思えばいくらでもできるんだから。これがXULアドオン時代の考え方でした。

他方、WebExtensionsでは、各アドオンは事前に許可された範囲の情報しかアクセスできないので、ユーザーは各アドオンの権限だけを気にすれば良いという事になっています。この事ばかりが強く印象に残っていたことと、とにかくXUL版から機能を移植するという事にばかり気を取られていたために、アドオン同士の間ですらもアクセスできる情報の範囲に差があるという事が、頭の中からすっかり抜け落ちていたのだと思います。

「アドオン同士の権限に差がある」というWebExtensionsの世界に合わせるには、TSTやMTHのAPIにもその考え方を反映しないといけなかったんですね。自分のアドオンが正当な手順でWebExtensions APIから入手した情報は、相手のアドオンにとっても同様に正当な手順で入手できる情報だ、とは限らないのです。それを忘れて呼び出し元の求めに応じてなんでも返してしまっていたというのは、「内緒にするから教えて」と言って教えてもらった情報を、他人にホイホイ言いふらすようなものです。実に嘆かわしいです。

2つ目の理由は、permissionsで宣言する権限の影響範囲を正しく把握しきっていなかったこと。

tabsという権限の名前からはいかにも、タブに関する事なら何をするのにも、例えばタブの一覧を取得するのにすらも必須であるような印象を受けます。TSTやMTHのAPIを呼ぶには呼び出し側のアドオンがタブのIDを知っている必要があり、タブのIDを知っているなら当然tabsの権限も持っているはず、ならタブのプロパティ全部渡しても問題無いはず（どうせ呼び出し側のアドオンが自分でも同じ情報を取得できるんだから）。というのが、これらのAPIを作った時点での自分の認識だったのだと思います。

しかし実際には、tabs.query()などのWebExtensions APIはtabsの権限無しでも呼ぶ事ができます。tabs/activeTabの権限の有無は、タブの一覧を取得できるかどうかではなく、返されるタブの情報にタイトルやURLなどのセンシティブな情報が含まれるかどうかという点にだけ影響します。TSTやMTHをWebExtensionsで実装するにあたって、まだWebExtensionsの仕様への理解が浅かったかなり初期の時点でtabsの権限を設定したきりだったために、この勘違いがずっと正されないまま今に至ってしまっていたのでしょう。他のアドオンを作る時にも、自分はひょっとしたらtabsの権限が不要なのに要求してしまっているという例があるかもしれません。

今回のことから得られた教訓は、以下のようにまとめることができると思います。

• それぞれの権限が何を可能にするのか、その権限が無いと何ができなくなるのかを、ちゃんと理解しておく。不要な権限は要求しないようにして、常に必要最小限の権限だけをpermissionsには列挙する。
• WebExtensions APIから自分の権限で取得したオブジェクトをそのまま使い回して、他のアドオン向けのメッセージに含めてはいけない。必ず、センシティブでない事が分かっている情報だけをホワイトリスト形式で抽出して、スクラッチでメッセージを組み立てること。

僕のように「他のアドオン向けのAPI」を提供するアドオンを作ろうと思っている方は、どうか僕と同じ過ちを犯さないように、他山の石として下さい……

「お疲れ様」が失礼とかそういう話 - May 12, 2019

自分は「ご苦労様」というフレーズが「目上の人に使うのは失礼な言葉だ」「代わりに『お疲れ様』なら言ってもいい」と言われるようになった過程を見てきた世代の人間なので、「お疲れ様」が今「目上の人に使うのは失礼な言葉だ」と言われるようになっているという話を見かけて、まあ驚きましたね最初は。

「ご苦労様」が咎められていた頃にも「そもそも、目上の人に『ご苦労様』と言う例は昔からあった」とか色々反論は目にしましたが、結局みんな馬鹿馬鹿しいとは思いつつも、それで失礼だと言われたら怖いとビビって「ご苦労様」を目上の人には使わなくなったと思うので、「お疲れ様」もそのうちみんなビビって使わなくなるのかもしれません。

捏造マナーを広めてマッチポンプで仕事を作り出す失礼クリエイター（自称「ビジネスマナー講師」）に踊らされるのは癪だなあと思いつつ、しかし、お疲れ様もご苦労様も目上の人に言うのは失礼だというのは案外当を得ているのではないか？という気がする部分もあります。

というのも、「お疲れ様」が目の敵にされるようになった時にも「それは目上の者が目下の者の労をねぎらう時の言葉だからだ」と説明されていて、今回の「お疲れ様」でも同様の言われ方をしているようなので、そもそも「労をねぎらう」というのが「上から目線」の行為という事なのではないだろうか、だとしたら、目下の側からねぎらいの言葉が発される事自体が失礼扱いされるのは致し方ないのでは、と思ったのですね。

現代で「お疲れ様です」が発されるのってどういう場面なんでしょうか。「労をねぎらう」と一言で言ってしまっているケースでも、分析してみると実は色々なコンテキストがあるんじゃないでしょうか。

• その人が自分のために労を割いてくれたので。
• その人が自分のしたミスの尻拭いをしてくれたので。
• 自分が関わる事ではないが、その人が何か仕事をこなしたので。
• 見るからに疲れている様子なので。
• すれ違いざまの挨拶として。メールの書き出しとして。

相手が労を割いてくれたという事だと、「ありがとうございます」という表現がより適切な気がします。

相手が尻拭いをしてくれたという事だと、「ご迷惑をおかけして済みません」の方が適切に思えます。

自分の関係ない所でその人がした事に対して、何も言わないのは失礼だから何か言いたいという時は、「素晴らしいお仕事です」とか「敬服致します」とか言える気がします。

見るからに疲れている様子なら、「お疲れのご様子なので今日はどうぞお帰り下さい」とかなんとか。

すれ違いざまの挨拶だと、その日の初回の遭遇だったら「おはようございます」「こんにちは」「こんばんは」が適切な気がします。2回目以降の遭遇では、どうなんでしょう。自分は「会釈」「黙礼」でいいと思いますが。ちなみに、最近読んでる「総務部総務課　山口六平太」では、典型的な日本型大企業の中で平社員が社長に遭遇したという場面では平社員が黙礼するだけという描写が多い印象があります。

こうして改めて「お疲れ様」「ご苦労様」の言い換えを考えてみると、他の言葉がより適切な場合もあるし、そもそも適切な・しっくりくる他の表現が無い場面もある、という気がしてきました。

「ご苦労様」って、かなり広い場面で使えるユニバーサルな言葉という気が僕はするのですよね。「それさえ言っておけばまあ大丈夫」というカテゴリの言葉というか。語彙力が無いと、それだけで全部済ませたくなっちゃうというか。だとすると、個別のコンテキストに応じた適切な言葉の使い分けを面倒臭がって、万能のフレーズ1つであらゆる場面を済ませてしまう怠惰さは、言われた相手の側にするといい気がしない、というのは一理ある気がします。少なくとも自分は、「自分のためにわざわざありがとうございます」「自分の不始末でご迷惑をおかけしてすみませんでした」等が適切な場面で「お疲れ様です」と言われたら、「なに他人事みたいに言うてんねん」とイラってなりそうです。「お疲れ様」が失礼となるケースがもし現実にあるとしたら、そういうケースが該当していそうな気がします。

そうでなく、しっくりくる表現が他に無いから「お疲れ様」が使われているというケース、挨拶やメールの書き出しのような場面が問題だとするなら、そもそも「ねぎらいのフレーズ」を無関係の場面に流用したのが間違いだった、ということはないでしょうか。言った側は「流用したフレーズを以て挨拶しただけ」のつもりが、相手はそれを流用ではなく本来の意味の使われ方すなわち「目上の者が目下の者に対して言う言葉」と捉えたために、失礼と感じられた、という事だったりしないでしょうか。

だとしたら、もういっそのこと、既存の言葉を流用しないでその場面に適した言葉を新しく作った方が建設的ではないでしょうか。例えばこんな感じで。

• 平社員が社長とエレベーターで乗り合わせた。黙っているのも変なので、挨拶する。「社長、きゆゎぶです！」
• 部下が上司にメールを書こうとしている。相手がいつ読むか分からないので「おはようございます」と言うのも変だ。なので、こう書き出す。「めでぺづです、結城です」。

「ランダム 文字列」で検索したら任意の文字数のひらがなの文字列を自動生成できるページが見つかったので、これで作った文字列を造語として流行らせてみると面白いのではないかという気がしています。社内で流行らせた結果、うっかり社外の人にまで使ってしまうとどうなるか分かりませんが……もしかしたら案外世間で流行るかもしれないですよね。「拝承」みたいに。