半角カタカナということですかね？
なんにせよ、URLエンコードした結果を書けばいいとは思います（実際のログイン時（成功時）に送っている POST データを見れば分かります）。

実際に送っている POST を見る方法は、ブラウザによって名称は違いますが、「開発者ツール」みたいな機能を使うと見られると思います。私が普段使っている Firefox なら ツール→ウェブ開発→ネットワークで、POSTの行で右クリック→編集して再送信、で、「要求ボディ」の欄に表示されるみたいです。
参考
https://private.hibou-web.com/archives/5390
https://gist.github.com/honda0510/4160295

＞要求文字列に日本語は使用できないのでしょうか？

これを見て思い出しました。文字コードの問題がありましたね。
日本語も使えますが、UTF-8 の場合だけです。それ以外だと日本語は使えません。
＃マニュアルに明記してあるといいんですけどね・・・。
うまくいかなかったのはこれが原因のような気がします。

念のため確認ですが、1. というのはログイン成功時の画面に含まれて失敗時には含まれない文字列ですか？
失敗時にも 1. が含まれるなら、ログインが成功かどうかに関係なく Web 監視の結果は OK になってしまいます。なので、ログイン後のページが UTF-8 でないなら、成功時だけに含まれる「アスキー文字だけの文字列」を要求文字列にするといいです。

以下、一応書いておきます。

memberNum や inputPass は、日本語でないにしても、記号を含んでいたりしませんか？
一部の記号はそのままではなく URL エンコードした値を指定する必要があります。
＃どの文字を URL エンコードするかは実は結構ややこしいので、
＃実際にブラウザが送信しているデータを見るのが一番楽。

＞　POSTデータを確認した結果、ログインボタン部分は「submit：ﾛｸﾞｲﾝ」でした。
submit：ﾛｸﾞｲﾝ と表示されたのは、たぶん開発者ツールの中で、見ている場所が違うんでしょう。
実際に送った文字列（※１）を表示しているところではなく、POST でどんな内容を送ったか（※２）を表示しているところを見たのだと思います。

違いを説明するのが難しいですが、
※１は「実際に送信したのは memberNum＝xxx&inputPass=yyy&submit=%zz%zz%zz%zzという文字列だよ」
※２は「memberNum の値として xxx を、inputPass の値として yyy を、submit の値として ﾛｸﾞｲﾝ（をエンコードしたもの）を送ったよ」
という感じです。

ただ、submit の値は、関係なさそうな気もするので、忘れてしまってもいいです。

ログインページの仕様が分からないのであくまで一般論ですが・・・
・ログイン処理に必要なのは基本的に名前とパスワードだけ。
・ログインボタンの文字列も送信されるのは、フォームに入っているからついでに送信される、というだけのこと。
・ログイン処理をするプログラムでは、普通、ログインボタンの文字列は無視する。
もちろんログインボタンの文字列を読んでそれに応じて処理を変える、といった処理も可能ですが、そのようにしたくなる場面はそうそう無いと思います。

まとめると、
・たぶんパラメーター指定は今のままで大丈夫（なんなら 最後の & 以降は消してもいい）。
　ただし memberNum や inputPass が記号を含むなら URL エンコードする必要があるかもしれない。
・ログイン後のページが UTF-8 でないなら要求文字列に日本語は使えない。
　日本語以外で、ログイン成功時にのみ含まれる文字列を指定する。

うーん、ちょっと分からないですね・・・。

curl -L -i -d POSTデータ ログイン情報送信先のURL
だとどうなりますか？ログイン後のページのHTMLが出力されますか？
＃Zabbix が curl に実際どういう引数をつけているのかは調べていませんが、
＃たぶんこんな感じかなと思います。

＞リダイレクトをたどる：チェックあり
これは、おそらく curl の -L オプションを付けるということなんだろうと思いますが、-L オプションは Location: ヘッダーと 3xx の応答を見てリダイレクトの判断をするようなので、meta タグや JavaScript でリダイレクトするときは対応してなさそうな気がします。
その場合、リダイレクト前のページ（=ログイン情報送信先のURL）を見るステップの他に、その次にリダイレクト先のページ（URL）を見るステップが必要となるのかもしれません。

また、サイトの作り次第ですが、例えばログイン情報入力ページで cookie などを設定してからログインページに移らないとログインできないようにしてある場合は、最初のステップで入力ページ、次のステップでログイン情報送信先ページをチェックする必要があるでしょうね。

まだよく分かりませんね。
もしかして、ログイン情報送信先もログイン情報入力ページも同じで、パラメーター（か、Cookie など）で動作が変わる、ということ？

どうも分かりにくい（＆話がしにくい）ので、一部を伏せてでもいいので、以下の URL（(1)(2) はブラウザのアドレスバーに表示されるもの）を書いてみてもらえませんか。
(1) ログイン情報を入力するページ
(2) ログイン後に表示されるページ（ログインボタンを押して移動した先）
(3) onclick で設定されている action 先
(4) curl で試した URL

＞Web画面遷移はログインボタンに設定してある「onclick」コードで「名前(this)」と命令が行き、
＞命令先で「action」が設定されておりログイン後画面に遷移する流れのようです。
これは、想像するに、フォームの機能を無効にした上で、ログインボタンを押したら通常のフォームの動作を JavaScript が代わりに行う、ということなんでしょう（値の送信前に何か処理（入力値のチェックなど）を挟みたいときに、こんなふうにすることがあります）。

curl を使うと、その action 先に遷移したときに、なぜかログイン情報入力画面（に相当するHTML）が取得される、ということで合ってますか？