Visual Studio 2022（VB.NET / .NET Framework 4.8）からメインフレームへTN3270接続したいのに、標準ライブラリが見当たらず手が止まることがあります。本記事では「どの方式が現実的か」を整理し、OSS活用・端末エミュレータ連携・自前実装のポイントとVB.NETで始める具体例までまとめます。
VB.NETでTN3270接続が「意外と簡単にいかない」理由
TN3270は「TCPでつなげば終わり」という単純な話ではなく、Telnetのオプション交渉（BINARY/EORなど）を経て、3270データストリームをやり取りする仕組みです。TN3270の“成立条件”を満たさないと、相手はNVT（普通のTelnet ASCII）として扱うため、つながったのに画面が出ない・文字化けする・入力が効かない…といった現象が起きます。
また、TN3270E（Enhanced）になると、LU名選択やAID（PFキー/PAキー/ATTNなど）周りの扱いがより本格的になります。さらに3270の世界ではEBCDICが基本で、クライアント側がASCII↔EBCDIC変換を担う前提の整理も必要です。
つまり「.NETの標準クラスだけで、すぐに安定したTN3270クライアントが書ける」タイプの話ではなく、専用ライブラリ（OSS/商用）を使うか、端末エミュレータを自動化するのが現場的に強い選択肢になります。Microsoft Q&Aでも、IBMなどが公式に提供していない場合はTCP/IP処理を自前で抱えることになりやすい、という趣旨で案内されています。
最初に決めるべき「目的」：ログインして画面を操作？それとも疎通確認だけ？
同じ「TN3270接続したい」でも、目的によって最適解が変わります。まずは、要件をこの3つに分解してください。
- 疎通確認：指定ホスト/ポートが開いているか、接続が落ちないかをチェックしたい
- 端末操作（画面スクレイピング/入力自動化）：ログインして、画面遷移して、項目入力や取得をしたい
- 企業要件（監査/SSO/暗号化/運用）：TLS、監査ログ、サポート、ライセンス、更新性が必要
| 目的 | おすすめの方向性 | 理由 |
|---|---|---|
| 疎通確認だけ | TCPレベルのヘルスチェック + 可能なら“簡易TN交渉” | フルの3270エミュレーションは過剰。運用監視の入口として有効。 |
| 画面操作を自動化 | Open3270などのOSS / もしくは端末エミュレータAPI（HLLAPI/COM） | 3270データストリーム解釈を自前で抱えない方が早い。 |
| 企業要件が強い | 商用エミュレータ + .NET API / 既存導入エミュレータの自動化 | サポート、暗号化、監査、更新計画を取りやすい。 |
方式比較：VB.NETでTN3270接続を実現する現実的な選択肢
| 方式 | 実装難易度 | 向いているケース | 注意点 |
|---|---|---|---|
| OSSライブラリを直接利用（例：Open3270） | 中 | 自前アプリ内で接続〜画面操作まで完結したい | 保守状況、既知不具合、TLS対応、ライセンス確認が必須 |
| 端末エミュレータを自動化（IBM PCOMM/Reflection等のCOM/HLLAPI/EHLLAPI） | 中〜高 | 既に社内標準エミュレータがある/運用統制が必要 | P/InvokeやCOM連携、32/64bit整合、端末起動状態に依存 |
| Microsoft Host Integration Server（HIS）系のAPI利用 | 中 | HIS基盤があり、SNA/ゲートウェイ経由で統制したい | API前提・学習コスト。セッションビジー/ロックの扱いが重要 |
| 自前実装（TCP/Telnet交渉/3270データストリーム） | 非常に高 | 特殊要件でライブラリが使えない、研究用途 | 工数が膨らみやすい。仕様理解・テスト環境・例外系が重い |
OSSで進める：Open3270をVB.NET（.NET Framework 4.8）から使う
「とにかく自前アプリから直接つなぎたい」場合の候補として、Open3270が挙がることがあります。Open3270.NETStandardはNuGet上で、VB.NET/C#を含む.NETアプリからTN3270/TN3270E接続を扱える高レベルAPIを提供すると説明されています。
ただし、パッケージの更新日やライセンス表記はバージョン/パッケージで差があるため要確認です。Open3270（1.5.0.1）は最終更新が2017年と表示され、ライセンス表記も“GPL v2.1”となっています。Open3270.NETStandard（1.0.0.2）は2021年更新で、MITライセンス表記です。社内配布・商用利用の形態によっては、法務/調達を含めた確認を最初に済ませるのが安全です。
導入手順（Visual Studio 2022 / .NET Framework 4.8）
- VB.NETのプロジェクト（.NET Framework 4.8）を作成
- NuGetで Open3270.NETStandard（または要件に合うOpen3270系）を追加
- 接続先（ホスト/ポート/端末タイプ）を決め、まずは「接続→画面更新」まで通す
Open3270.NETStandardは .NET Framework 4.8 でも利用可能な対象に含まれる形で表示されています。
VB.NETサンプル：接続して画面をRefreshする最小例
Open3270利用者の例として、C#では TNEmulator を作り、端末タイプを設定して Connect → Refresh するコードが紹介されています。これをVB.NET向けに書き換えた最小例が次です。
Imports Open3270
Imports Open3270.TN3270
Public Class MainframeClient
Public Sub ConnectAndRefresh(host As String, port As Integer)
Dim emulator As TNEmulator = Nothing
Try
emulator = New TNEmulator()
' デバッグ出力の有無（環境によりプロパティ名が異なる場合があります）
emulator.Debug = False
' 端末タイプ（例：IBM-3278-2-E など）
emulator.Config.TermType = "IBM-3278-2-E"
' 画面取得を高速化するモードがある場合は有効化
emulator.Config.FastScreenMode = True
' 接続（第三引数はライブラリ側の仕様により意味が変わるため、まずは Nothing で開始）
emulator.Connect(host, port, Nothing)
' 画面更新（例：強制更新 + タイムアウトms）
emulator.Refresh(True, 20000)
' ここまで来れば「接続して最初の画面が取れた」段階
' この後は、画面テキスト取得/フィールド操作/キー送信などを実装していきます。
Catch ex As Exception
' 実運用では例外メッセージだけでなく、ホスト/ポート/端末タイプ/タイムアウトもログに残すと解析が速い
Throw
Finally
' Disconnect/Dispose 等は、利用しているOpen3270実装のAPIに合わせて明示的に実行してください。
End Try
End Sub
End Classポイントは、まず「つながること」と「最初の画面が更新できること」を最小化して確認することです。いきなりログイン自動化まで入れると、ネットワーク・端末タイプ・LU・コードページ・アプリ側の画面状態（キーボードロック）など、原因切り分けが難しくなります。
Open3270系を使うときの実務チェック
- 保守状況：古いパッケージ/リポジトリだと、環境差で例外が出ることがあります（例：Refresh時の例外報告など）。
- TLS/暗号化：接続先が“Telnet over TLS”前提の場合、ライブラリが素で対応していないことがあります（要件として事前確認）
- 端末タイプ：3270は端末タイプ＝画面サイズ/属性サポートに直結します。端末タイプ末尾の「-E」は拡張データストリームを扱えることを示す、という説明があります。
- LU指定：特定LUを指定しないと接続できない構成があります（TN3270Eで顕著）。Open3270.NETStandardは“特定LU指定の接続”をサポートすると説明されています。
端末エミュレータを“連携して使う”という発想：HLLAPI/COM/DDEは今も強い
企業の現場では「既にエミュレータ（IBM PCOMMやReflectionなど）が標準導入されている」ことが多く、その場合はエミュレータを自動化するのが最短で堅い選択肢になります。理由は単純で、TN3270/TN3270Eの面倒をエミュレータに任せられるからです。
IBM Personal Communications（PCOMM）：COM（HACL）で画面・フィールドを扱う
IBM PCOMMは自動化のためのオブジェクトを提供しており、ドキュメントにはVB系の例として CreateObject("PCOMM.autECLPS") で接続し、フィールドリストから GetText する例が掲載されています。VB.NETでも同じ発想で実装できます（COM参照を張るか、遅延バインディングで呼び出します）。
' ※この例は「IBM PCOMMがインストール済み」であることが前提です
' まずは遅延バインディングで動かし、必要に応じてCOM参照で型付けします。
Public Class PcommAutomation
Public Function ReadFirstFieldText(connectionName As String) As String
' connectionName はPCOMM側のセッション名（例："A"）など
Dim ps As Object = CreateObject("PCOMM.autECLPS")
' 接続先セッションを指定（環境により "A" のような名前）
ps.SetConnectionByName(connectionName)
' フィールド一覧を更新して、先頭フィールドのテキスト取得
ps.autECLFieldList.Refresh()
Dim textStr As String = CStr(ps.autECLFieldList(1).GetText())
Return textStr
End Function
End Classこの方式の利点は、画面が“フィールド”として扱えることです。3270は「入力可能領域」「保護領域」を持つため、フィールド単位の操作ができると、座標ベタ打ちのスクレイピングより壊れにくくなります。
IBM PCOMM：EHLLAPI（DLL）をP/Invokeで叩くルートもある
COMではなくEHLLAPIを使う例も多く、実際に「PCOMMインストールに含まれるDLL（pcsapi32.dll / pcshll32.dll）をP/Invokeして使った」という報告もあります。C#でも同様なので、VB.NETならDeclare/Interopで実装できます。
ただし、P/Invokeはシグネチャ・文字コード・32/64bit・スレッドモデルなどの罠が多いので、最初はCOM（HACL）で成立させ、性能や制約で必要になったらEHLLAPIに寄せる、という順番が安全です。
TN3270 Plus：DDEで画面取得やマクロ実行が可能なケース
TN3270 PlusはDDEサーバとして動作でき、セッションに接続したり、画面（Presentation Space）を要求する、といった関数が案内されています。DDEは古い仕組みですが、既存運用があるなら“今すぐ動く”可能性があります。
またWinHLLAPIのC#サンプルが配布されているため、VB.NETでは「C#サンプルを読み替える」か「C#部分をライブラリ化してVBから参照する」作戦が取りやすいです。
Microsoft Host Integration Server（HIS）を使っているなら：API仕様を理解すると強い
HIS環境がある場合、「HISのTN3270エミュレータ/セッションAPI」を軸にする手もあります。たとえばHost Integration Serverのドキュメントには、Icom3270.sendKey がキーストロークを送るメソッドであり、セッションがビジー/ロックの場合のエラーや、入力許可を待つためのwait利用が示されています。
“キーボードロック”や“セッションビジー”は3270自動化の最大の落とし穴です。送信を急ぎすぎると取りこぼしが起き、逆に待ちすぎるとタイムアウトだらけになります。APIが提供するwaitやOIA（オペレータ情報エリア）相当の状態確認を組み合わせるのが王道です。
自前実装ルートが難しい具体例：Telnet交渉とEOR/BINARY
どうしてもライブラリが使えない場合、TCPソケットを開いた上で、Telnetのオプション交渉（IAC DO/WILLなど）を実装し、TN3270として成立させる必要があります。RFC 1576には、EOR（End Of Record）やBINARYを双方で交渉し、その後に <3270 data stream> IAC EOR 形式でやり取りする例が掲載されています。
| 自前実装で必要になりやすい要素 | 何が難しいか | 失敗した時の症状 |
|---|---|---|
| Telnetオプション交渉（TERMINAL-TYPE / BINARY / EOR 等） | 相手実装の癖・順序依存がある | 接続はできるが画面が出ない、途中で切れる |
| 端末タイプ設計（例：-E対応） | 画面サイズ/属性/拡張データストリームが絡む | 列数が合わない、属性が崩れる |
| 3270データストリームの解釈 | 書き込み命令・属性バイト・フィールド制御など | 文字が取れない、入力位置がズレる |
| ASCII↔EBCDIC変換 | コードページ差・ダブルバイト混在など | 文字化け、キー入力が別文字になる |
加えて、TN3270Eの整理として「ASCIIとEBCDICの変換はクライアント責任」という趣旨が説明されており、変換が曖昧なまま進めると日本語や記号周りで必ず詰まります。
VB.NETでC#ライブラリを使うコツ：最短で安定させる“現場の型”
TN3270関連のOSSはC#で提供されていることが多く、VB.NET側で無理に全面移植するより、C#でビルドしてVBから参照する方が安全です。Microsoft Q&Aの回答でも「まずC#プロジェクトとしてコンパイルしてVBから参照」「プライベートNuGetがあるならパッケージ化すると管理しやすい」という実務的な流れが推奨されています。
おすすめ構成（小規模〜チーム運用まで対応）
- TN3270接続層：C#クラスライブラリ（Open3270などを参照）
- 業務アプリ層：VB.NET（WinForms/WPF/サービス等）
- 配布：社内NuGet（または社内ファイルサーバでDLL配布）
社内NuGetにすると何が嬉しい？
- 依存関係（Open3270.NETStandardなど）をプロジェクトごとに手で合わせなくて済む
- 更新時の差分が追いやすい（バージョンで制御できる）
- “誰のPCで動く/動かない”を減らせる（同じビルド成果物を使う）
トラブルシューティング：ありがちな詰まりポイントと対策
症状：接続できるが画面が空白／変な幅になる
- 端末タイプが合っていない：3270は端末タイプで画面サイズが変わります。Open3270の例でも端末タイプを明示しています。
- -E（拡張データストリーム）前提の画面：末尾「-E」が拡張対応を示す、とRFC 1576に記述があります。
症状：キー送信が効かない／途中で止まる
- キーボードロック/セッションビジー：3270はホスト処理中に入力がロックされます。HISのsendKeyドキュメントでも、ビジー/ロック時にエラーが返り、waitで入力可能になるまで待つ旨が示されています。
- AIDキーは最後に送る：AIDキーを送ると、その後のバッファが無視され得る、という注意がHISドキュメントにあります。自動化では「文字列入力→最後にEnter/PF」を徹底すると安定しやすいです。
症状：OSSで例外が出る／環境差で落ちる
- パッケージの更新日とIssueを確認：Open3270（1.5.0.1）は2017年更新と表示されています。更新が止まっている場合、OSやネットワーク条件で不具合が表面化することがあります。
- まずは最小コード（Connect→Refresh）で再現性を取る：ログイン自動化を外し、接続と画面更新だけの再現を作ると切り分けが速い
導入前チェックリスト：これを押さえると手戻りが減る
| チェック項目 | 確認する内容 | 実務メモ |
|---|---|---|
| 接続先情報 | ホスト名/IP、ポート、プロキシ/ゲートウェイの有無 | 監視だけなら疎通確認も先に作る |
| プロトコル | TN3270かTN3270Eか、LU指定が必要か | TN3270EはLU名制御などが重要になりやすい |
| 端末タイプ | 3278/3279、-E対応、画面サイズ（24×80/27×132等） | 端末タイプが画面崩れの主因になりやすい |
| 文字コード | EBCDIC/コードページ、DBCSの扱い | クライアント側変換が必要という整理を早めに |
| 自動化設計 | キーボードロック待ち、タイムアウト、リトライ | waitや状態取得があるAPIを優先 |
| ライセンス/配布 | OSS/商用の利用条件、社内配布形態 | NuGet表記や社内配布ルールを確認 |
結論：VB.NETでTN3270接続を成功させる“最短ルート”
Visual Studio 2022（VB.NET / .NET Framework 4.8）でTN3270接続を実現するなら、最初から「自前実装で全部抱える」より、次の順で進めるのが成功確率が高いです。
- 最短で自前アプリに組み込みたい：Open3270.NETStandardなどのOSSで「Connect→Refresh」までを最小コードで通す（要：保守状況/ライセンス確認）
- 社内標準エミュレータがある：PCOMM（COM/HLLAPI/EHLLAPI）や、既存エミュレータのAPIを叩く（運用統制が強い）
- チーム運用を見据える：C#ライブラリ化→VB参照→社内NuGet配布で依存関係を固定する
TN3270は“プロトコルの癖”と“運用要件”が絡みやすい領域です。まずは、あなたの組織で使えるエミュレータ/既存基盤（PCOMM、HIS、Reflection等）の有無を確認し、使えるものがあればそこに寄せる。どうしても直接実装が必要な場合は、Open3270のようなライブラリの活用から始める。これが現実的な最短ルートになります。
コメント