JUST FYI

JUST FYI

多分すごくどうでもいい事。誰かの何かの参考になれば。むしろ自分用覚え書きかも。

※この記事は「スプレッドシートにバインドしたGAS」を対象としています。また筆者はAIが書いたスクリプトをコピペするだけの作業を半年続け、やっと最近自分でスクリプトを書き始めたばかりのド素人です。細かな間違いはご容赦ください。

  ちょっと視点を変えて考えてみた

 

AppSheetからGASを実行する方法は2つあって、いずれもBOTを使うものではあるのだが、

  • Call a webhookを使う方法
  • Call a scriptを使う方法

がある(ちなみに何がどう違うのかは全くわからない)。私が今まで使っていたのはCall a webhookを使う方法で、その理由は単純に最初にGASを使ったときにChatGPTがその方法を教えたからなのだが。

 

検証後にAppSheetとGASの解説記事をいくつか調べてみると、ほとんどの記事が

 

  ・Call a scriptを使う方法

 

を使っていた。読んでみると、Call a scriptをのほうが設定が簡単そうだということも判明、試しにやってみることにした。さらに調べるとCall a scriptを使うにはバインドのGASではなくてスタンドアロンのものを使わないといけないことが判明。ファイル作り直しか・・・と思いながら試してみると。

 

なんと、巻き添えデリートが起こらなかった!!

 

Call a scriptにしたからなのか、スタンドアロンにしたからなのかは分からないが、とにかく巻き添えデリートが起きないことが判明!チャッピーよ、なぜ最初からこっちを教えてくれなかったのか。

 

 

  さらに考察を続けてみる

 

BOTの発火条件についても、参照した記事の方式と私が使っていた「フラグアクション方式」には違いがあることが分かった。そもそもこの方式、AppSheetからのデータ変更ではGASのonEditが動作しない問題の解決策として(AIに言われるままに)導入したのだが、参照記事では

  • BOTは「Adds / Updates」で発火

という構成を取っていた。考えてみれば単純な話でである。私が作っているアプリの中には、「住所が入力/変更されたら座標を取得する」というGASがあるのだが、それなら住所Adds/Updatesを発火条件にすればいいだけの話で、わざわざフラグ列など作る必要はなかったのだ。こちらもまた、最初に知った方法を「これ以外ない」と思い込んでいたために気づかなかったが、変更を発火条件にすることで、疑似的にonEditを実現できていたのだ。

 

もちろんフラグ方式が無意味というわけではない。

  • 「ある出来事があったら必ずやる」処理ならAdds/Updates発火。
  • 「ユーザーが『今やって』と言った時だけやる」処理ならフラグ発火。
使い分けをすることでより便利にAppSheet×GASを使うことだできるだろう。
 

 

  まとめ

 
今回の検証で「巻き添えデリートの原因が完全に分かった」とまでは言えないが
  • バインドのGASで
  • Call a webhookを使用して
  • フラグを戻す設計 
を使用している限り、この現象から逃れることはできなさそうだと推測できた。
そしてこの問題の当面の回避策として
  • フラグを戻さない設計
  • Call a scriptとスタンドアロンのスクリプトを使う設計
についても学ぶことができた。
 

今までは、AppSheetからGASを呼ぶなら

  • バインドGAS
  • Call a webhookを使用
  • フラグを立ててBOTを発火
  • 処理後にフラグを戻す

方法しかないと思い込んでいたが、改めて調べてみると、イベントそのものを発火条件にする書き方もあると知ることもできた。

 

もし私と同じように、AppSheet・BOT・バインドGASという構成で謎の挙動に悩んでいる方がいれば、この記録が少しでも参考になれば幸いだ。

 

※この記事は「スプレッドシートにバインドしたGAS」を対象としています。また筆者はAIが書いたスクリプトをコピペするだけの作業を半年続け、やっと最近自分でスクリプトを書き始めたばかりのド素人です。細かな間違いはご容赦ください。

 

  はじめに

 

AppSheetからGASを実行する方法として、BOTから呼び出す構成はよく紹介されている。私自身この方法をずっと採用していたが、ある問題にずっと悩まされていた。

それは、私が勝手に「巻き添えデリート」と呼んでいた現象だ。

現象

【定義:巻き添えデリートとは】
BOTでフラグをFALSEに戻した際、GASが書き込んだ内容だけが元の状態に戻ってしまう現象
 

フラグがTRUEになることでBOTをで発火させてCall a webhookを実行、GASでスプレッドシートを書き換える処理を実行。その後フラグをFALSEに戻す。

この時、フラグを戻すタイミングで、GASにより書き換えた内容が実行前の状態に戻る。

  • AppSheetの不具合なのか
  • GASの書き方が悪いのか
  • BOTの設定なのか

何が悪いのかまったく見当がつかない。検索してみても更新内容が消える記事なんて一つもない(後から分かったことだが、AppSheetとGASの解説記事の多くはスタンドアロンGASを前提としており、私とは構成そのものが異なっていた)。

 

  原因を探すためにやったこと

 

本番アプリでは他にもBOTや式が多数動いているため、原因の切り分けが難しい。変なところをいじって全体をおかしくしてしまうのも怖い。

そこで、本番とは別に実験用アプリを作成し、条件を一つずつ変えながら検証してみた。これにより

「何が原因ではないか」

を一つずつ消していくことができた。

 

 

  試したこと

 

 

試作アプリ「巻き添えデリート研究」

使用シートは一つだけ、カラムとして、ID Flag Text1 Text2 Text3を設置

AppSheet上でFLAG=TRUEのアクションを作成

このアクションボタンを押すことをBOT発火条件とする

ここまでを共通事項として、条件を変えて何回か実験を行った。


実験1:単純なフラグの上げ下げ

    準備:Text1に適当な文字列を入力

    BOTプロセス:FlagをFALSEにする

結果:Text1に変化なし。単純にフラグだけが切り替わる

   フラグの上げ下げだけが問題ではないらしい

 

実験2:GASを使用した場合

    準備:スプレッドシートにバインドのスクリプトを作成

       Text2に「GASからの入力」と表示するだけのもの

    BOTプロセス:Text1に「BOTからの入力」と表示

           Call a webhookで呼び出したGASを実行

           Text3に「GASからの入力」と表示

           FlagをFALSEにする

結果:FlagがTRUEになる→Text1~Text3がそれぞれ表示される→FlagがFALSEに変わり、Text2が空欄に戻る

巻き添えデリート発生!!

ラグなのか実行タイミングなのかシート上での表示の順番は異なることがあるものの、最終的な結果はすべて同じ。GASからの入力だけが白紙撤回される結果となった。

 

実験3:念のためBOTのプロセスの順番を入れ替えてみる

    準備:実験2と同じ

    BOTプロセス:最初にGAS実行、その後BOTからの書き込み(2列)、その後フラグオフ

結果:実験2と同様巻き添えデリート発生。実行順は問題ではないらしい。

 

実験4:フラグのある行と編集行を別にしてみる

    準備:データを一行追加。追加した行のフラグをオンすることで、もともとあった行にGASとBOTから書き込みをする。

    BOTプロセス:実験2と同じ

結果:巻き添えデリート発生せず!!

フラグがあるのと同じ行のみ巻き添えが発生するらしい。そういえば本番アプリでもフラグが別シートにあったときは巻き添えは発生しなかった。

 

 いずれのケースでも、フラグをFALSEに戻す動作がない場合にはGAS入力が消えることはなかった。また、フラグを戻す方法については、GASで戻す場合でもBOTのプロセスで戻す場合でも結果に違いはなかった。

 唯一違ったのは、フラグ戻しをBOT終了後に別のアクションボタンで行った場合であるが、これはBOTと切り離された別操作なので当然のことであろう。

 

  ここまででの考察(対策について)

 

ここまでの実験で、一連のBOTでフラグを下げる動作をする限り基本的に巻き添えデリートは避けられないことがわかった。避けることができるのは
・書き込みをする行とは別の行やシートにフラグを置く
・フラグを戻す動作を別のアクションで行う
・そもそもフラグを戻さない運用にする
のいずれかを選んだ場合のみ。
 
次にそれぞれの方法の実用性について考えてみる。
・書き込みをする行とは別の行やシートにフラグを置く
  →実装が面倒。AppSheet上でアクションボタンを表示する際、他シートだとアクションが複雑になる。
・フラグを戻す動作を別のアクションで行う
  →単純に面倒だし意味不明。誤操作のもとでもある。
・そもそもフラグを戻さない運用にする
  →一度TRUEにしたものをFALSEに戻せないとなると再実行ができない。T/F方式ではなくてカウンター方式(実行ごとに数字を+1するなど)にして、フラグ列updateをBOT発火条件にするのが現実的か。

 

(つづく)

 

 

時々、ChatGPT(チャッピー)と会話をして遊んでいる。

あるとき、「使いづらいエクセルファイル」の話題で盛り上がり、「エクセル地獄ランキング」なるものを作ったことがあった。
 

■ 完成!Excel地獄ワーストテン👑
ついに揃ったw👇

1位:1セル複数データ(即死)
2位:セル結合(広範囲破壊)
3位:数字+単位混在(分解必須)
4位:数字が文字列(静かに壊れる)
5位:スクロール誤爆(参照混入)
6位:連続データコピー事故 🆕
7位:ドラッグ移動事故 🆕
8位:全角半角・謎スペース
9位:日付が文字列
10位:空白行乱入

👉 “あるある度”と“殺傷力”のバランスがいい神リストw

その時はそれで終わったのだが、ふと思い立った。
「これ、AIに頼んで画像化してみたら面白いのでは?」
せっかくなので複数のAIに同じ内容で作らせ、チャッピーと2人(?)で出来上がりを見比べることにした。作らせたのはチャッピー(①)、Gemini(②)、Copilot(③)の三者。日ごろから公私共にお世話になっている面々だ。

プロンプトは全員同じで、上記のランキングを提示したうえで

この内容を職場や学校で掲示する啓発ポスター風の画像にしてください。

とした。

 

  

 

結果は予想以上に違った。あるAIは感情に強く訴える方向に振り切り、「あなたのミスが地獄を招く」と警告する。別のAIは全体を整然と構成し、教育資料のような雰囲気を作る。そしてまた別のAIは堅実にまとめ、業務上の注意喚起として成立する形に仕上げる。それぞれに明確な傾向があり、見ているうちに「このAIはこういう性格だ」と言いたくなってくる。

・やりたいようにやる自由人①。
・育ちのの良さを隠し切れない優等生②。
・会社で隣の部署とかにいそうな生真面目な会社員。③

ちなみにチャッピーにどれを誰が描いたか当ててもらったところ、自分の分だけバッチリ当ててきた。さすがである。

ここまででも十分面白いのだが、何かが足りない。もう少し遊んでみたい。そう、これは「エクセル地獄ワーストテン」。地獄成分が足りないのだ。そこで最初の生成で「地獄」ワードを使わなかった2つのAIに、同じプロンプトで再び指示を出した。

もっと地獄感の強い、見た人が思わず足を止めるような感じにできますか?

ここから様子がおかしくなった。



優等生は、世界ごと壊しにきた。建物が崩れ、炎に包まれる。これはもはや災害のスケールといえるだろう。「地獄感」を視覚的にわかりやすくした結果、現実からはやや遠ざかってしまった。そのくせ「生産性を向上させましょう」という啓蒙活動も怠らない。地獄にあっても育ちの良さからくる他者へのやさしさは健在だ。

とはいえこれはちょっと地獄の度が過ぎる。エクセルのミスでこうはならないだろう。そこで、

世界が崩壊するような地獄でなくていいので、「現実のオフィスで起きていそうな範囲」の地獄でお願いします。

とお願いしてみたところ、できたのがこちら。


控えめな地獄を期待していたのだが、出てきたのは物理的に崩壊しかけているオフィスだった。どうやら解釈としては「現実でも起きうる=災害レベル」という方向に振れたらしい。だからエクセルで災害は起きないんだってば。

左下にはなぜかトレッドミルのようなものに乗って疲れ切った様子で歩いている人物がいた。進んでいるようで進んでいない、いくら頑張っても前に進まない様子は、ある意味で最も正確な「地獄」表現かもしれない。

一方、真面目そうな会社員も負けてはいない。

 

(なぜか一部白抜けしてしまった)

炎や鎖などの要素を追加し、ポスターとしての完成度を保ったまま順当に“強化”してくる。過不足なく、意図を外さない。これはしごでき会社員の匂いを感じる。しかもこの会社員、

もしこの地獄感をさらに強調したいなら、
黒背景+赤い照明で“地獄の会議室”風にする
各項目に「破滅度★☆☆☆☆〜★★★★★」の評価を追加する
下部に「Excel救済の書(正しい入力例)」を添える
などのアレンジもできます。どんな方向に進化させたいですか?

と、拡張パックの提案までしてくる。面白がっていろいろ追加変更を加えた結果、出来上がったのがこちら。



この違いを見ていると、AIごとに「何を優先するか」がはっきりしてくる。

インパクトを優先するもの。
整合性や正しさを優先するもの。
実用性や読みやすさを優先するもの。

そして、それぞれがその優先順位に従って、同じ素材をまったく別の形に仕上げていく。

さて、話はここから変わる。
「AI、画像の修正で言うことを聞かない問題」である。

生成した画像の文字を消して背景だけにしてほしいと頼んだときのことだ。ワースト「テン」なのだから、ランキング枠は10個あるべきなのに、なぜか9個になっていた。

こちらは素直に「9個しか入らない」と伝えた。すると返ってきたのは「高さは十分あるはずです」という趣旨の説明だった。しかも「あなたの文字の入れ方が悪いのでは?」と言わんばかりの口調である。これにはさすがにちょっとイラっとしてしまった。

高さ(スペース)の問題ではない。
枠の数の問題だ。

仕方がないので、行番号を振った画像を用意して説明した。これでさすがに伝わるだろうと思ったところ、今度は枠が11個になった。ご丁寧に1~11の行番号付きで。

どうしてそうなった。10でいいんだよ10で。

戸惑いつつ11はいらないと伝えたところ、枠数は11のまま、行番号の記載のみ1~10、という代物が生み出された。もしかしておちょくられていたのだろうか。

さらに、再生成を重ねるたびに頼んでいないところまで微妙に変わっていく。

人間は「ここだけ直す」つもりで指示を出すが、AIはその都度、全体をそれっぽく作り直している。だから一部が直る代わりに、別の部分が静かに変わる。

また、画像内のパーツの位置関係についても苦戦した。
「このパーツをこのパーツの真上において。スペースは開けないで」
何度頼んでも全くスペースが詰まっていかない。より具体的な表現のほうがいいのかと思い、

現在の状態が

上パーツ
(空白)
(空白)
下パーツ

なので、

上パーツ
(空白なし)
下パーツ

にしてほしい

とまで説明したが、それでも変わらない。どうもAIと私とでは、「間をあけない」の認識が異なるようだ。その証拠に全く前と変わらない画像を生成し、自信満々に

完成しました

と言い、私の告げた説明を自慢気に復唱する。完成してないんだよ。言ったことやってくれていないんだよ。

この問題に対して有効だったのは、具体的な見本を提示する方法だった。言葉による説明では伝わらなかった内容が、画像で示すと一度で反映される。AIは抽象的な指示より具体例に強いようだ。

そしてもう一つ、重要な点に気が付いた。

すべてをAIに任せる必要はない、ということだ。
AIに頼むからといって、最初から最後までAIで完成させる必要はないのだ。

・構図や雰囲気はAIに任せる
・文字や細部は人間が調整する
・ピンポイントの修正は別のツールを使う

という分業のほうが、はるかに安定するし効率がよい。
不要な文字を消すときには、いわゆる「消しゴムマジック」のようなツールを使えばよい。これならほかの部分を巻き添えにすることがない。安全安心である。

今回、単なる遊びのつもりで始めたが、結果的には「AIの性格を前提に使い分ける」という、少し実践的な理解にたどり着いた。

AIは万能ではないが、それぞれに得意な役割がある。
そして、その役割を見極めて配置することが、人間側に求められている。

(おまけ)3つの中で唯一最初から地獄ワードを出してきたチャッピーに、さらに地獄感のあるものを作ってもらったのがこちら。

いややっぱAIすごいわ・・・。
 

 

 

 

 

 

 

 

 

 

 

 

 

【やりたいこと】

  • デッキ/テーブルビューでレコード表示の順番を上下するための矢印アクションを作る。カテゴリ分けされたレコードにおいて、カテゴリ内でのみ順序変更する。

使用カラム(Type)

[ID](Text)※UNIQUEID()

[レコード名](Text)

[カテゴリ名](RefでもEnumでも)

[並び順](Number) カテゴリごとに10スタート10刻みの数字

[カテゴリ内順位](Number)

[順位被りチェック](Yes/No)

[カテゴリ内レコード数](Number)

 [カテゴリ内順位最大値](Number)

[並び順更正要否](Yes/No)

各カラムを以下のように設定

[並び順]
initial value
IF(
  ISBLANK(
    MAX(
      SELECT(
       テーブル名[並び順],
       [カテゴリ名] = [_THISROW].[カテゴリ名]
      )
    )
  ),
  10,
  MAX(
    SELECT(
      訪問予定[並び順],
      [カテゴリ名] = [_THISROW].[カテゴリ名]
    )
  ) + 10
)
 
[カテゴリ内順位]
COUNT(
  SELECT(
    テーブル名[ID],
    AND(
      [カテゴリ名] = [_THISROW].[カテゴリ名],
      [並び順] < [_THISROW].[並び順]
    )
  )
) + 1
 
[順位被りチェック]
COUNT(
  SELECT(
    テーブル名[ID],
    AND(
      [カテゴリ名] = [_THISROW].[カテゴリ名],
      [カテゴリ内順位] = [_THISROW].[カテゴリ内順位]
    )
  )
) > 1
 
[カテゴリ内レコード数]
COUNT(
  SELECT(
    テーブル名[ID],
      [カテゴリ名] = [_THISROW].[カテゴリ名]
  )
)
 
 [カテゴリ内順位最大値]
MAX(
    SELECT(
      テーブル名[カテゴリ内順位],
      [カテゴリ] = [_THISROW].[カテゴリ]
    )
  )
 
[並び順更正要否]

OR(
  [順位被りチェック],
  [カテゴリ内レコード数] <> [カテゴリ内順位最大値]
)

以下のアクションを作成

「上へ」

Data: set the values of some columns in this row

[並び順]=[並び順]-11

Only if this condition is true

[カテゴリ内順位]<>1

(意味)[カテゴリ内順位]が1でないときのみ表示。[並び順]を11減らす

 

「下へ」

Data: set the values of some columns in this row

[並び順]=[並び順]+11

Only if this condition is true

[並び順]
<
MAX(
  SELECT(
    テーブル名[並び順],
      [カテゴリ名] = [_THISROW].[カテゴリ名]
    )
  )

(意味)[並び順]がカテゴリ内最大値でないときのみ表示。[並び順]を11増やす

 

「上へダミー」

Data: set the values of some columns in this row

[ID]=[ID](何もしない)

Only if this condition is true

[カテゴリ内順位]=1

(意味)[カテゴリ内順位]が1の時、「上へ」の代わりに表示

 

「下へダミー」

Data: set the values of some columns in this row

[ID]=[ID](何もしない)

Only if this condition is true

[並び順]
=
MAX(
  SELECT(
    テーブル名[並び順],
      [カテゴリ名] = [_THISROW].[カテゴリ名]
    )
  )

(意味)[並び順]がカテゴリ内最大の時、「下へ」の代わりに表示

 

「再採番」

Data: set the values of some columns in this row

[並び順]=[カテゴリ内順位]*10

(意味)後述のカテゴリ内再採番のもととなるアクション

 

「カテゴリ内再採番」

Data: execute an action on a set of rows

Referenced Table テーブル名

For a record of this table テーブル名

Referenced Rows 

SELECT(
  テーブル名[ID],
  [カテゴリ名] = [_THISROW].[カテゴリ名]
)

Referenced Action 「再採番」
(意味)「上へ」「下へ」アクションで変更した並び順を、10刻みに整形する

 

「カテゴリ変更時再計算」

Data: set the values of some columns in this row

[並び順]=
IF(
  ISBLANK(
    MAX(
      SELECT(
        テーブル名[並び順],
               [カテゴリ名] = [_THISROW].[カテゴリ名]
      )
    )
  ),
  10,
  MAX(
    SELECT(
     テーブル名[並び順],
      [カテゴリ名] = [_THISROW].[カテゴリ名]
    )
  ) + 10
)

 

(意味)日付変更時に、移動先の最後尾に配置する

 

ユーザーが入力するのは[レコード名][カテゴリ名]のみ。

 

BOTの作成

BOTは二つ作る。
1.整列BOT
Updates only
Condition
[_THISROW].[並び順] <> [_THISROW].[カテゴリ内順位] * 10

Run a data action
Referenced rows
SELECT(
  テーブル名[ID],
  [カテゴリ名] = [_THISROW].[カテゴリ名]
)
Action
「再採番」
(意味)並び順が崩れたとき、カテゴリ内の全行を整列する
Run a data actionではなくGroup actionで「カテゴリ内再採番」を選んでも同じ意味
 
2.カテゴリ変更BOT
Updates only
Condition
[_THISROW_BEFORE].[カテゴリ名] <> [_THISROW_AFTER].[カテゴリ名]


Step1
Set row Values
[並び順]=
IF(
  ISBLANK(
    MAX(
      SELECT(
        テーブル名[並び順],
               [カテゴリ名] = [_THISROW].[カテゴリ名]
      )
    )
  ),
  10,
  MAX(
    SELECT(
     テーブル名[並び順],
      [カテゴリ名] = [_THISROW].[カテゴリ名]
    )
  ) + 10
)

Step2
Run a data action
Referenced rows
SELECT(
  テーブル名[ID],
  [カテゴリ名] = [_THISROW].[カテゴリ名]
)
Action
「再採番」
(意味)カテゴリ移動があったとき、並び順を移動先の最大値+10にする
並び順が崩れるので、全行を整列する
 

管理用ビュー(オプション テーブルビュー)

推奨表示カラム カテゴリ名でGroupしておくと見やすい

[レコード名](Text)先頭5文字程度にカットすると見やすくなる

[並び順](Number)

[カテゴリ内順位](Number)

[順位被りチェック](Yes/No)

[カテゴリ内レコード数](Number)

 [カテゴリ内順位最大値](Number)

[並び順更正要否](Yes/No)

ほか、上下アクション、カテゴリ内再採番、並び順を+1するアクション(別途作成)などお好みで配置

実際に並べ替えを使用するビューのDetailあたりにリンクのアクションを置いておくと飛びやすい

 

実際に使用するビューの設定(重要)

Sort byを[並び順] Ascending に設定する ※これをやらないと動きません!
(理由)上下アクションで直接変更しているのは並び順。それ以外のたくさんのアクションやBOTは並び順を整列して後の上下アクションに備えているだけだから。

 

 

 
 
 少し前に撮った写真ですが。

イメージ 1


イメージ 2

 これだけの衣装を身に着けておとなしくしていられるってすごいと思いません?
 絶対ないと困るというわけでもないけれど、持って行って助かった役立ちアイテムを列挙。 *個人の感想です

・100円ショップで売っている折り畳みのスリッパ
    ・靴生活の国ではホテルの部屋にスリッパは存在しない
    ・靴脱ぎ文化で育った日本人としては歩かないときは靴を脱いでリラックスしたい
    ・軽くてかさばらないので持ち運びが楽
    ・旅行が終わったらそのまま捨てても惜しくない

・日本茶のティーバッグ
    ・炭酸や甘い飲み物が苦手な方におすすめ
    ・海外では無糖のペットボトル飲料はほぼ水のみ
    ・毎日水ではさすがに飽きる
    ・500ml程度のペットボトルの水に放り込んでおけば一晩で水出し緑茶の出来上がり
    ・しかしそのままだと(ペットボトル入りの緑色の水が)不気味がられるのでペットボトルカバーもあったほうがいい
    ・滞在泊数分くらい持っていけば充分足りると思う

・シートパック
    ・空調や水の違いで肌が乾燥しがち
    ・ドラッグストアで売っている安いやつでいい(人によると思います)

・1000~2000円くらいの安物の腕時計
    ・普段は携帯で十分でも、旅行中は時間を気にすることが多くなる
    ・落としたり壊したりしてもあまり泣かないですむ
    ・いかにも高そうな時計をしているとお金持ちそうに見えて治安面で不安(?)
    ・時差に合わせて簡単に現地時間に直せる(電波時計とかその辺面倒そう)


 お金をかければいい旅ができるというものでもありませんが、お金がなければお話にならないのも事実。かかった費用について。

≪円建てで計算できるもの(カード決済分)≫
航空券 85,320円 
    ・楽天トラベルで購入
    ・本来の価格は115,320円で他社より1000円ほど高かった
    ・たまりにたまった楽天スパーポイントを限界まで突っ込むことによりこの金額になった

宿泊費 63,099円
    ・楽天トラベル経由でBooking.comから予約
    ・評判のよさ重視で選んだので結構高くついた
    ・金額はカード請求額の合計

交通費 10,982円
    ・湖水地方までの往復チケットとツアー代金

食費     788円
    ・スーパーでサンドイッチとか果物とか購入

≪現地で現金で払ったもの≫
交通費 £37.65
    ・空港→市街へのトラム(片道) £4.20
    ・湖水地方でのバス乗り放題2日分 £16
    ・ヒルトップへ向かう船+バス £6.15
    ・湖水地方からの帰りで空港まで乗り越した分 £4.80
    ・空港~市街へのオフピーク日帰り往復 £4.90
    ・マンチェスター博物館までのバス(往復) £1.60

入場料等 £24.2
    ・Hill top £11(寄付金付き)
    ・Beatrix Potter Gallery £6 (寄付金なし)
    ・The World of Beatrix Potter Attraction £7.2
    ・マンチェスターの各博物館は無料

その他 食費・飲み物代・お土産・雑費 £81.05
    ・レシートがないのでもはや詳細は不明
    ・おそらく£40くらいが食べ物だと思われる
    ・昼食はカフェなどで£5程度
    ・夕食はスーパーでサンドイッチと果物などで軽く済ませて£5弱

≪どちらが有利?カードVS現金≫
    ・出発時に成田で30000円をポンドに両替。レートは148.09円で200ポンドと388円のお釣りが来た
    ・この日の朝レートを調べたところ138円くらいだったので、1ポンド当たり10円が手数料だったと推測される
    ・カード決済分は日によって違うが139円~142円だった
    ・今回現金で払ったところでも、カード不可のところはほぼなかった(バス代くらいか)
    ・少額(数百円程度)でも現地人は普通にカードで払っている
    ・現金を余らせると再両替が必要になり、また手数料がかかる
    ・最低限の金額(5000円くらい?)を現金で持ち、基本はカード払い、現金が不足したら現地でキャッシング、が一番無難かつお得と思われる

≪で、全部でいくらかかったの?≫
    ・カード決済分 160,189円
    ・現金支払分   21,162円
    ・合計      181,351円


 



 旅に情報収集は必須。情報源のまとめ。

ガイドブック
  ・何でも好きなものを使えばいいと思う
  ・わたしは昔から「地球の歩き方」派だったので今回もそれを利用
  ・紙ベースだと重いしかさばるので電子書籍をダウンロード。全体ではなく一部ダウンロードができて便利だった。
  ・しかしスマホの小さい画面で見るのは少々苦しかった
  ・イマドキはなんでもwebで情報が集められるのでガイドブックは不要、な印象もあるが、全体像をつかむためにも一度は見ておくといいと思う。

現地でもらえるパンフレット等
  ・やはり現地の情報は新鮮で正確。大いに活用すべし
  ・利用には多少は英語力が必要。たまに日本語のものもある

webサイトを活用するために
  ・最近のホテルなら大体そうなっているが、無料wifiがあると心強い
  ・自分のスマホを海外で使うためにはどうしたらいいか事前にちゃんと調べておく
  ・わたしはsimフリーのスマホなので、現地用のsimを購入した(日本で)。現地でも買えるけど面倒だし時間がもったいないので(買うまで通信できないし・・・)。30日有効で1GB。


お役立ちアプリ
    ・あらかじめ必要な地域のデータをダウンロードして使う
    ・地域によって情報量が異なるようだが(日本のわたしの家の周りはしょぼかった)行ったエリアでは結構充実していた。
    ・Google Mapにくらべ、コントラストがはっきりしていて屋外でも見やすい
イメージ 1


左がGoogle Map 右がMaps.Me 好みもあるけど私は右側のほうが見やすいと思う

    ・スケール表示されているので距離がわかりやすい
    ・オフラインマップなので圏外でも安心

    ・乗換案内のイギリス版
    ・使い方は日本の乗換案内とほぼ同じ
    ・アプリから直接予約もできるらしい
    ・イギリス国外で使うと時刻表示がおかしくなるのでプランニングには使えない

    ・イギリス製の天気予報アプリ
    ・かなり細かく地域選択できる
    ・一時間ごとの予想気温、天気、降水確率等みることができる
    ・ウィジェットも利用できる。結構おしゃれ

    ・ガイドブックを落として持って行った
    ・ま、別に、ほかのアプリでもいいと思いますけど
    
 泊まったホテルと大雑把な感想、宿泊料金

マンチェスター市内
  ・市の中心部のわかりやすい場所にある
  ・大きな建物の一部がホテルになっている模様
  ・鉄道駅、トラムの駅いずれからも近く、周辺には食べ物屋やスーパーもあり便利
  ・部屋はきれい。バスルームもわりときれい。日本の基準から言うとややお湯の出が少ない
  ・朝食はバイキング形式
  ・料金は朝食付きで£50

ウィンダミア
 ケンブリッジハウス(Cambridge House)
  ・ウィンダミア駅から徒歩5分ほど
  ・石造りの素敵な建物
  ・部屋、バスルームともにきれい。ここもやはりお湯の出がいまいち。
  ・朝食は食堂で。時間は8:30~とやや遅め
  ・オーナーは明るく親切。
  ・目の前が小さなスーパー。一分歩くとまた別のスーパー。食べ物屋もいろいろあって便利。
  ・チェックインすると部屋のカギと玄関のカギをセットで渡される。玄関のカギは開けるのにコツがいるのでレクチャーを受けたほうがいい。
  料金は3泊朝食付きで£267

マンチェスター空港近く
  ・基本的には駅からも空港からも送迎バスが必要
  ・送迎バスは駅または空港に呼び出し用の電話があるのでそれで呼び出す
  ・面倒だからと言って歩いていくと交通量の多い道を横切ることになりとても危険。というかそもそも歩いていく人がいることは想定されていないっぽい。
  ・バスが面倒な人は駅直結の別のホテルのほうがいい(高いけど)。わたしはもし次回があればそうする。
  ・しつこいが駅から送迎バスというのは何気に面倒で、いったんホテルに入った後またどこかへ出かける、という気にはあまりなれない。ホテル内にレストランもあるが、何か買って部屋で食べたい、という場合は先に買っておかないと後悔することになる。
  ・部屋は広く、バスルームもきれい。お湯がたくさん出て気持ちいい。
  ・料金は朝食なしで£135

おまけ 
  ・フライト遅れで航空会社が手配してくれたホテル
  ・上に書いたクレイトンホテルのお隣。よって交通条件も全く同じ。
  ・部屋は広い。バスルームもきれい。お湯は使っていないのでわからない。

 各ホテルに共通していたのは、バスタオルが馬鹿でかいこと。体の大きさの違いなのか・・・? あと、シャンプーなどは基本的についていたが、歯ブラシはなかった。

 

 今回の旅行の諸々まとめ。事実と考察、主観が入り混じっているので注意。

イギリスまでの往復
  ・エティハド航空を利用。初めて聞く会社だったが普通に快適だった。
  ・機内食が(私には)おいしかった。
  ・夜間便だとアメニティグッズをもらえる模様(ヘッドフォンの袋に一緒に入っていた)
  ・紙製のクッションが各席についているが、これがなかなかの優れもの
イメージ 1
ぜひ各航空会社に導入していただきたい
  
  ・拠点となる空港はアラブ首長国連邦のアブダビ。大きく立派な空港で、ド早朝に到着したにもかかわらず免税店がフルオープンしていた。ものすごいやる気だ。
  ・今回のルートだと往路の乗り継ぎが長かったのがやや難。しかし待ち時間で時差ボケを吸収(?)できるともいえるので悪いことばかりでもないかもしれない。
  ・遅延はまあ・・・仕方ないよね。みなさんとても親切にしてくれたし。

マンチェスター空港~市内の移動
  ・鉄道がおすすめだと思う。列車にもよるけど20分ほどで到着し、本数も多い。
  ・ただし行き先には注意が必要。マンチェスターに行かない列車もある模様。
  ・料金は時間帯で変わるがオフピーク時で£4.80。Day Return(日帰り往復)は£4.90。なぜ10ペンスしか違わないのか・・・。
  ・トラム(Metrolink)で行くことも可能。しかし時間がかかるうえ市の中心部まで直行ではないのでやや不便。料金は片道£4.20。日本の路面電車と違って切符は乗る前に駅で買う。
  ・バスの便もある。行先によっては便利かもしれないが乗っていないので詳細は不明。

マンチェスター市内の移動
  ・トラムとバスがある。
  ・バスには普通の有料のバスのほか、市内中心部を巡回する無料バス、メトロシャトル(Metroshuttle)がある。
  ・サイトに路線図があるが、正直言って素人には理解不能。なぜ普通の地図の上に路線を乗せてくれないのか。
  ・でも無料だし本数も多いのでとりあえず乗ってみて地図アプリでどこを走っているのか確認しつつ移動するのもいいと思う。あと海外のバスには珍しく「次は○○」とバス停の名前を言ってくれるのは便利。

マンチェスター~湖水地方の移動
  ・鉄道を利用。オフピークの往復チケット(一か月有効)で£36.10。
  ・イギリスの鉄道には特急とか急行とか行った種別がないらしく、目的地までの経路上の列車ならどれに乗ってもいい模様。
  ・一つの路線を複数の鉄道会社が列車を運行しているので、どの路線だったらどの会社の列車、という明確な決まりはない。もちろん、山手線だったら緑の帯、みたいな一貫性もない。
  ・駅や車内のアナウンスはそれなりに親切だが、日本ほどではない。何も言ってくれない列車もある。
  ・一等と二等がある。買い間違い、座り間違いに注意。
  ・数分程度の遅れは誤差の範囲。駅には「遅れ10分以内での運行率90%!!」とか書いたポスターが自慢気に貼ってある。
  ・時刻表は路線ごとのものが駅にたくさんあって無料でもらえる。ただし、自分に必要なものを探すのが結構大変。
  ・切符は人のいるカウンターでも買えるが自動券売機が便利。先に行き先や切符の種類を選び、金額が確定してからお金/カードを入れる。
  ・駅には基本的に改札はない。車内改札が必ず来る。ちゃんと切符を買ってないと罰金らしい(自信なし。でもとにかく厄介なことになるらしい)。

湖水地方での移動
  ・鉄道はないのでバス移動。自転車の人もたくさんいた。ウィンダミア駅前にレンタサイクルあり。
  ・湖水地方全体のバス路線図&時刻表があり、非常に使えるので手に入れておくべし。わたしは駅併設のスーパー入り口にあったパンフスタンドで手に入れた。
  ・路線や本数はかなり充実している。
  ・バスに乗るときは運転士に行き先を告げ、その分のお金を払う。降りるときは降車ボタンを押して降りる。わたしの知る限り海外のバスはこのシステムが多いけど、ずいぶん人の良心を信用したシステムだなと思う。あと、降りるバス停の名前がわからないと困る。
  ・一日乗車券もある。ウィンダミア周辺のみの一日乗車券で£8。よほどの短距離乗車でない限り2、3回使えば元が取れるのでお得。もっと広い地域の一日乗車券や、7日間乗り放題のチケットもあり、ある程度バスを使うなら十分元が取れる。
  ・初めての湖水地方で右も左もわからない、というときはツアーもいい。
  ・わたしが使ったのはマウンテン・ゴートという会社のツアー。全編英語だが結構わかりやすい。日本語で案内してくれるところもあるようだが詳細は不明。
  ・ツアーは効率的に回れるがかなり忙しい。ツアーで概要をつかんで、気に入ったところに翌日以降ゆっくり行きなおすのも一つの手か。