Tiny Core Linux 17.1とは｜ISOの選び方・必要スペック・日本語化とインストール手順

Tiny Core Linuxは、起動時にシステム全体をRAMへ読み込んで動く超軽量のLinuxディストリビューションです。2026年10月12日時点の現行版は17.1で、CLI専用のCoreは20,658,176バイト、GUI付きのTinyCoreでも27,262,976バイトしかありません。公式FAQに載っている起動の下限はRAM 46MB、CPUはi486DXです。ただし、17.0をISOから起動して測った利用者の報告では、もっと多くのRAMが必要でした（後述）。

この記事では、配布されている17.1のISOを実際に展開して、カーネルの版、USBやUEFIで起動できるISOの違い、インストーラの選択肢、日本語化に必要な拡張機能を確かめました。小ささだけで選ぶと、UEFI専用機で起動しない、日本語が打てない、再起動で設定が消える、のどれかで止まります。その3つを先に潰す順番で説明します。

まとめ：Tiny Core Linux 17.1を使う前に押さえる要点

• 現行版は17.1。x86のISOは2026年7月16日から17日付で、カーネルは6.18.35、BusyBoxは1.36.1です。
• ISOは5種類あり、起動できる環境が違います。UEFIで起動できるのはTinyCorePure64だけで、CoreとCorePure64はUSBへddで書いても起動用にはなりません。
• 公式FAQの下限はRAM 46MB・CPU i486DX。ただし公式フォーラムの利用者による17.0の計測では、ISOから起動するとCLIで71MB、GUIで90MBが必要でした。実用には128MB以上を見込みます。
• 日本語化は4つに分けて設定します。ロケール（getlocale）、キー配列（kmap）、フォント、入力です。入力は64bit版ならfcitx-anthy、32bit版はuimのSKKに外部の辞書を足す形になります。
• 再起動するとRAM上の変更は消えます。拡張機能はtceディレクトリ、設定とデータは/opt/.filetool.lstとmydata.tgzで残します。
• 常用デスクトップには勧めません。キオスク端末、検証用の使い捨て環境、Raspberry PiのpiCoreのように、毎回同じ状態で起動したい用途で強みが出ます。

Tiny Core Linuxの仕組みと17.1の中身

Tiny Coreの配布サイズが小さい理由は、基本システムを最小限に絞り、ブラウザなどを拡張機能として別途追加する構成にあります。基本システムをRAMへ展開する起動方式は、これとは別の特徴です。公式のCore Conceptsは、ストレージからRAMへ自分自身を読み込み、アプリケーションはストレージ上にマウントするか、RAMへインストールすると説明しています。システムファイルは変更から守られ、再起動すると手つかずの状態に戻ります。

17.1の構成：カーネル6.18.35・BusyBox 1.36.1・Xvesa

Core-17.1.isoを取得してmd5を照合し、中身を展開すると、カーネルは6.18.35-tinycore（2026年6月19日ビルド）、ユーザーランドはBusyBox v1.36.1でした。/etc/os-releaseのVERSION_IDは17.1です。版を確かめるコマンドはLinuxのバージョン確認：OS確認コマンドの早見表とos-release・unameの使い分けと同じで、Tiny Coreでもそのまま使えます。

カーネル6.18系はkernel.orgの長期サポート版で、保守の予定は2028年12月までです。ただし2026年10月12日時点で上流の6.18系は6.18.56まで進んでおり、Tiny Core 17.1の6.18.35とは差があります。上流の修正がTiny Coreの配布物に入ったかどうかは、リリース告知と配布ファイルのカーネル版で確かめる必要があります。ネットワークにつなぎっぱなしの端末に使うなら、この確認を運用に組み込んでください。

GUI付きのTinyCoreが使うXサーバーはXorgではなくXvesaです。.xsessionはXvesa -screen 1024x768x32で起動し、解像度はブートコードxvesa=800x600x32のように変えられます。

最低RAM 46MB・CPU i486DX｜公式FAQの下限と推奨

公式FAQの「What are the minimum requirements?」は次のとおりです。

• RAMの絶対的な下限は46MB。これ以下では、スワップを何テラバイト用意しても起動しない
• Microcoreは28MBのRAMで動作する
• CPUの下限はi486DX（数値演算プロセッサ付きの486）
• 推奨構成はPentium 2以上、RAM 128MBに加えて多少のスワップ

この46MBは、どの起動方法でも通る数字ではありません。公式フォーラムでは、利用者が17.0の32bit版をQEMUで起動して必要なRAMを測った報告（2026年3月）があります。ISOをCDとして起動すると、CLIは71MB、GUIは90MBを下回ると起動しませんでした。カーネルとinitrdを直接読み込ませる形なら、46MBでCLIが起動しています。起動直後の空きはGUIで約13MBしかなく、報告者は実用には128MB以上が要ると結論付けています。

RAM上で全システムが動く方式は、メモリを使い切った時点で破綻します。17.1は起動スクリプトのtc-configが空きメモリ（MemFree）の4分の1をzram（RAM上の圧縮スワップ）として自動で有効にしますが、これはRAMを圧縮して延命する仕組みで、物理RAMの不足を補うものではありません。128MB前後の機体で常用するなら、Linuxのスワップ領域(swap)とは｜確認・推奨サイズ・vm.swappinessの設定を実コマンドで解説を参考に、ディスク上のスワップも用意してください。

5種類のISOの選び方｜サイズ・USB起動・UEFI対応の違い

公式ダウンロードページの表記（Core 17MB、TinyCore 23MB、CorePlus 248MB）は、配布ディレクトリの実ファイルと一致しません。下の表のサイズは配布ディレクトリの実バイト数です。USB起動とUEFIの列は、各ISOの先頭セクタ（MBR署名）とEl Toritoのブートカタログを読んで判定しました。

CoreとCorePure64はMBR署名を持たないため、ddでUSBメモリへ書いてもBIOSが起動ディスクとして扱いません。仮想マシンやCDとして起動する用途向けです。USBから試すならTinyCore、CorePlus、TinyCorePure64のどれかを書きます。CorePlusは7種類のウィンドウマネージャ、無線LANのファームウェア、US配列以外のキーボード対応、インストーラを同梱した「インストールイメージ」で、20MB台の他のISOとは別物です。

32bit版と64bit版の選び分け

Tiny Coreは2026年時点でも32bit（x86）版を現行で配布している数少ないディストリビューションです。選び方はハードウェアで決まります。

• UEFIしか持たない機体：TinyCorePure64一択です。表のとおり、UEFIの起動情報を持つのはこのISOだけです。
• CPUが64bit非対応の古い機体：x86版を選びます。BIOS（またはUEFIのCSM）で起動します。
• 日本語入力を手早く使いたい：x86_64版を選びます。かな漢字変換のanthy系が配布されているのは64bit側だけです。

カーネルモジュール系の拡張機能は、17.x系では6.18.2向けと6.18.35向けが並存しています。17.1のカーネルは6.18.35なので、uname -rで確かめてから版が一致する拡張を入れます。

インストール手順｜ISOの取得からUSB起動・tc-installまで

仮想マシンで試すだけなら、ISOをCDとして割り当てれば最初の手順だけで動きます。

ISOのダウンロードとmd5照合

ISOと同じ場所に.md5.txtが置かれています。中身はハッシュとファイル名の1行なので、そのままmd5sum -cに渡せます。

curl -O http://tinycorelinux.net/17.x/x86/release/TinyCore-17.1.iso
curl -O http://tinycorelinux.net/17.x/x86/release/TinyCore-17.1.iso.md5.txt
md5sum -c TinyCore-17.1.iso.md5.txt

64bit版はパスのx86をx86_64に、ファイル名をTinyCorePure64-17.1.isoに替えます。

USBメモリへの書き込みと起動メニュー

Linuxから書き込むときは、書き込み先のデバイス名を先に確かめます。/dev/sdXを取り違えると作業用のディスクを消します。

lsblk -o NAME,SIZE,MODEL,MOUNTPOINT
sudo dd if=TinyCore-17.1.iso of=/dev/sdX bs=4M status=progress conv=fsync

WindowsならRufusやVentoyを使います。ツールごとの違いはArch LinuxのISOをUSBに書き込む手順｜dd・Rufus・Ventoyの使い分けとインストールまでの内容がそのまま当てはまります。

起動すると、TinyCore-17.1.isoとTinyCorePure64-17.1.isoは次の4項目を表示します。USBメモリで拡張機能を読み落とすときは、待ち時間付きの項目を選びます。

TinyCorePure64のUEFI起動に使うEFI/BOOT/efiboot.imgには、署名済みの起動ローダーであるshimが含まれていませんでした。セキュアブートが有効な機体で起動しないときは、セキュアブートとは？UEFIが署名でOSの起動を守る仕組みと有効化・確認・サーバー運用まで実装目線で解説の手順でセキュアブートを無効にしてから試します。

tc-installによるディスク導入と選択項目

ディスクへの導入には、CorePlusに同梱されているインストーラか、他のISOならtc-install.tcz（CLI版0.9）またはtc-install-GUI.tcz（GUI版0.8）を読み込んで使います。公式が標準とする方式はfrugal installで、カーネルとルートファイルシステムの2ファイルだけを置き、拡張機能とユーザーのデータはその外側に保存します。ディスク全体にファイルを散らす従来型は、公式が「scatter mode」と呼んで区別しています。

tce-load -wi tc-install
sudo tc-install.sh

tc-install.sh（17.x版）のソースを読むと、問われるのは次の順番です。

• 導入元：起動中のOS、CD、ISOファイル、ネットの4つ
• 導入の種類：Frugal（ハードディスク向け）、HDD（USBメモリ全体を1つのFATパーティションにする）、Zip（USBメモリを2つのFATパーティションに分ける）
• 対象：Frugalのときだけ「Whole Disk」か「Partition」を選べます。HDDとZipはドライブ全体を消します
• フォーマット：ext2、ext3、ext4、vfat（既存パーティションに入れるときは「none」も選べます）
• ブートコード：waitusb=5などを空白区切りで入力

注意点は、このインストーラが書き込むブートローダーがsyslinuxとextlinuxだけで、EFIを扱う処理を持たないことです。UEFIしか持たない機体のディスクへ入れるなら、リポジトリのgrub2-multi.tcz（GRUB 2.12、i386-pc用とx86_64-efi用を同梱）で自分でブートローダーを組む必要があります。

起動オプション（ブートコード）の早見表

frugal installの挙動は、ブートローダーに書くブートコードで決まります。17.1のISOに入っている一覧（F2〜F4キーで表示されるもの）から、よく使うものを抜き出しました。

公式Core Conceptsは、起動時にハードウェアの準備が間に合わないとTiny Coreはそのデータを諦めて起動を続けると書いています。USBメモリにtceディレクトリを置く構成でwaitusbを付け忘れると、「昨日まで読み込まれた拡張機能が今日は無い」という再現しにくい症状になります。

日本語化の手順｜ロケール・キー配列・フォント・入力の設定

Tiny Coreの初期状態はロケールがC、キー配列がusで、日本語フォントも入力メソッドも入っていません。日本語化はロケール、キー配列、フォント、入力の4つを別々に足していく作業です。

日本語化プロジェクト（tinycore-jp）の旧版と現行版の日本語化

日本語で検索すると「Tiny Core Linux 日本語化プロジェクト」が見つかります。これはOSDNにあったtinycore-jpという非公式プロジェクトで、2024年1月22日にWeb Archiveへ保存されたリリース一覧では、最新版が2012年5月20日の4.5.2です。osdn.net自体も2026年10月12日時点で応答しません。現行の17.1を日本語で使うなら、以下の手順で公式リポジトリの拡張機能から組み立てます。

ロケールとキー配列：getlocale.shとlang=・kmap=

lang=に日本語ロケールを指定しても、ロケールのデータが無いと効きません。getlocale.tczに入っているgetlocale.shが、選んだロケールからmylocale.tczを作り、tceディレクトリとonboot.lstへ自動で登録します。root権限で実行する作りなのでsudoを付けます。

tce-load -wi getlocale
sudo getlocale.sh
# 一覧から ja_JP.UTF-8 を選ぶ（mylocale.tcz が作られる）
tce-load -wi kmaps

ブートコードにlang=ja_JP.UTF-8 kmap=qwerty/jp106を足して再起動します。kmap=はkmaps.tczに入っている/usr/share/kmap/qwerty/jp106.kmapを起動時に読み込む指定で、効くのはコンソールのキー配列です。

日本語フォントの追加と32bit版の選択肢

32bit版と64bit版の両方にあるのはnotocjk-regular-fonts-ttc.tcz（Noto Sans/Serif CJK、37MB）です。

tce-load -wi notocjk-regular-fonts-ttc

32bit版には、これに加えてjiskan-fonts.tcz（JISのビットマップフォント、628KB）とmplus-fonts.tczがあります。RAMが128MB前後の機体で日本語フォントの使用時にメモリ不足が起きるなら、jiskanで表示だけ通すのが32bit版でしか取れない手です。

日本語入力：64bit版はfcitx-anthy、32bit版はuimのSKKと外部辞書

2026年10月12日に17.x系の拡張機能一覧を数えると、x86（32bit）は2,788件、x86_64（64bit）は3,614件でした。かな漢字変換の入り方は両者で違います。

64bit版はfcitx-anthy.tczを入れます。依存のfcitxとanthyはtce-loadが一緒に取得します。設定の置き場所は、17.1の起動スクリプトの読み込み順から決めました。~/.profileはstartxより前に~/.ashrcを読み、Xの起動後に~/.X.dの中のファイルを読みます。環境変数は~/.ashrcへ、常駐プロセスの起動は~/.X.dへ書きます。

tce-load -wi fcitx-anthy
echo 'export XMODIFIERS=@im=fcitx' >> ~/.ashrc
echo 'fcitx &' > ~/.X.d/fcitx

書き込んだだけでは、動いているXの画面には反映されません。filetool.sh -bでバックアップしてから再起動すると、次回の起動から入力メソッドが立ち上がります。どちらのファイルも/homeの下にあるので、既定のバックアップ対象に含まれます。気を付けたいのは更新の古さです。fcitx-anthy.tczの情報ファイルはバージョン0.2.3で最終更新が2018年1月5日、fcitx本体も4.2.9.5（2018年7月）のままです。

32bit版にanthyはありませんが、uim.tcz（1.9.6）にはSKK方式の変換エンジンlibuim-skk.soが入っています。足りないのは辞書だけで、uimの設定ファイルskk-custom.scmは既定で/usr/local/share/skk/SKK-JISYO.Lを探します。辞書はskk-dev/dictで配布されているSKK-JISYO.L（約4.5MB）を使います。BusyBoxのwgetはHTTPSに対応していないため、取得にはwget拡張を使います。

tce-load -wi uim wget ca-certificates
wget -O ~/SKK-JISYO.L https://raw.githubusercontent.com/skk-dev/dict/master/SKK-JISYO.L
echo '(define skk-dic-file-name "/home/tc/SKK-JISYO.L")' >> ~/.uim
echo 'export XMODIFIERS=@im=uim' >> ~/.ashrc
echo 'uim-xim --engine=skk &' > ~/.X.d/uim

辞書を/homeに置くと、毎回のバックアップ対象に辞書が加わり、圧縮・復元の処理量が増えます。mydata.tgzの増加量は辞書の圧縮率によって変わります。tceディレクトリと同じ永続パーティションに置いてパスを書き換えるほうが、起動時間を保てます。

tce-loadで拡張機能を管理する｜.tczの正体と3つの動作モード

Tiny Coreにはaptやdnfのようなパッケージマネージャが無く、tce-loadとそのGUI版のAppBrowserが拡張機能（.tcz）を取得して読み込みます。

.tczはsquashfsのイメージファイル

「tczフレームワーク」と呼ばれる仕組みの実体は単純です。nano.tczを取得してfileで調べると「Squashfs filesystem, version 4.0, zlib compressed」と表示されます。.tczは圧縮された読み取り専用のファイルシステムで、17.1のtce-loadのソースを読むと、.tczを/tmp/tcloop/拡張機能名に読み取り専用でループマウントし、cp -aisで中身へのシンボリックリンクをルート以下に張っています。リポジトリには本体と並んで、依存関係を書いた.tcz.dep、版と更新日を書いた.tcz.info、照合用の.tcz.md5.txtが置かれています。鮮度は.infoのCurrent行で確かめます。

tce-loadのオプション

17.1のtce-loadのソースは、使い方の表示に出る-i -w -o -l -c -sに加えて、上書きを許す-fと、tceディレクトリを指定する-tも受け付けます。

公式wikiのtce-loadのページは、取得済みの拡張機能に-wを使うと依存関係がインストールされないと注意しています。依存が壊れたように見えたら、まずこの条件を疑います。

Default・Mount・Copyの3つの動作モード

OnBootとOnDemandは取得時のオプションで、システムの動作モードではありません。Core ConceptsのModes of Operationは次の3つです。

• Default Mode（Cloud/Internet）：全てをRAMに読み込み、取得した拡張機能はそのセッション限りで消えます。再起動で必ず初期状態に戻ります。
• Mount Mode（TCE/Install）：拡張機能を永続ストレージのtceディレクトリに置き、起動時にマウントします。RAMを節約でき、公式は最も広く使われている推奨の方式としています。
• Copy Mode：マウントせずRAMへコピーします。copy2fs.flgで全部、copy2fs.lstで選んだものだけを対象にでき、起動は遅くなる代わりに実行は速くなります。

再起動で消さないための永続化設定

filetool.shとmydata.tgzによる設定の保存・復元

バックアップ対象を書くのが/opt/.filetool.lst、除外を書くのが/opt/.xfiletool.lstです。17.1の既定の.filetool.lstはoptとhomeの2行だけで、/homeと/optの全体が対象になります。パスは公式wikiの指定どおり、先頭のスラッシュを付けずにルートからの相対パスで書きます。

sudo sh -c 'echo etc/hostname >> /opt/.filetool.lst'
filetool.sh -b

-d（ドライラン）は17.1のfiletool.shのソースにあるオプションで、何がmydata.tgzに入るかと圧縮後のサイズを書き込まずに確かめられます。公式wikiのバックアップのページは、対象が増えるほど起動と終了が遅くなると書いています。ホームディレクトリ全体ではなく、設定ファイルと作業ディレクトリだけに絞るのが起動時間を保つコツです。

データ消失が起きる典型的な条件

• home=を使うのに.filetool.lstを直していない：home=で/homeを永続化しても、バックアップは止まりません。公式wikiは、永続化したhomeとoptを使うなら、ブートコードnorestoreでバックアップを使わないか、.filetool.lstからhomeとoptを外すよう案内しています。外さないと永続化した/homeまでmydata.tgzに入ります。
• 電源を直接落とした：バックアップはシャットダウン処理の中で行われます。終了メニューを通さないとmydata.tgzは更新されません。
• USB上のtceでwaitusbを付けていない：認識が間に合わなかった回だけ拡張機能が読み込まれません。

用途別の適性｜piCore・キオスク端末の利点と常用デスクトップの制約

公式のIntroductionは、Tiny Coreを「turnkey」のOSではないと最初に断っています。向き不向きがはっきり分かれるので、条件で判断します。

Raspberry Pi向けのpiCore 17.0

ARM向けの移植版がpiCoreです。2026年10月12日時点の配布ファイルは、32bit（armhf）がpiCore-17.0.1.img.gz（2026年9月5日付）、64bit（aarch64）がpiCore64-17.0.img.gz（2026年8月2日付）です。x86版の17.1とは版が揃っていません。

gunzip piCore64-17.0.img.gz
sudo dd if=piCore64-17.0.img of=/dev/sdX bs=4M status=progress conv=fsync

piCoreが効くのは、SDカードへの書き込みを抑えたい常時稼働の用途です。システムがRAM上で動くので、通常運用ではストレージへの書き込みがほとんど起きません。センサーの値を送るだけの監視ノードや単機能のサーバーに向きます。複数台の端末とデータ収集の仕組みまで含めて設計するなら、AI/IoTソリューションとして構成から相談する方法もあります。ストレージの選択はRaspberry PiでUSBメモリを使う方法｜公式Flash Driveの仕様・USBブート設定・fstab自動マウントも参考になります。

常用デスクトップに使うべきでない条件

• 日本語入力を毎日使う：64bit版の入力まわりの拡張機能は、fcitx-anthyが2018年、anthyが2020年の更新のままです。32bit版は辞書を自分で持ち込む必要があります。
• ネットにつないだまま長期間使う：17.1の配布カーネル6.18.35は上流の6.18.56から遅れており、修正の取り込みを自分で追う必要があります。
• トラブル時に日本語の情報を頼りたい：情報の中心は公式フォーラムとwikiで、いずれも英語です。

逆に、古いノートPCをWeb閲覧専用の端末にする、受付や展示のキオスク端末を毎回同じ状態で起動させる、検証用の使い捨て環境をUSBメモリ1本で持ち歩く、といった用途では、RAM上で動く基本システムと拡張機能を分けて構成できる点が利点になります。Default Modeなら再起動するだけで初期状態に戻るので、端末に変更が残らない点もセキュリティ面で効きます。軽いデスクトップを常用したいなら、最初からデスクトップ用途で設計されたHaiku OSとは？BeOS後継の軽量OS｜R1/beta6の特徴・インストール・使い道のようなOSも比較に入れてください。

よくある質問

Tiny Core Linuxとは何ですか？

起動時にシステム全体をRAMへ読み込んで動く、極小構成のLinuxディストリビューションです。2026年10月12日時点の現行版は17.1で、カーネルは6.18.35です。完成したデスクトップを提供するのではなく、必要な拡張機能を利用者が足していく土台として作られています。

Tiny Core Linuxのスペックはどれくらい必要ですか？

公式FAQによると、RAMの下限は46MBで、これ未満ではスワップの量にかかわらず起動しません。ただし17.0をISOから起動した利用者の計測では、CLIで71MB、GUIで90MBが必要でした。CPUの下限はi486DXです。推奨はPentium 2以上、RAM 128MBとスワップです。より小さいMicrocoreは28MBのRAMで動きます。

Tiny Core Linuxを日本語化するにはどうすればいいですか？

ロケール、キー配列、フォント、入力を別々に設定します。getlocale.shでja_JP.UTF-8のmylocale.tczを作り、ブートコードにlang=ja_JP.UTF-8 kmap=qwerty/jp106を足します。フォントはnotocjk-regular-fonts-ttc、入力は64bit版ならfcitx-anthy、32bit版はuimのSKKに外部の辞書を組み合わせます。

Tiny Core Linuxの日本語化プロジェクトは今も使えますか？

OSDNにあった非公式のtinycore-jpは、2024年1月にWeb Archiveへ保存されたリリース一覧で確認できる最新版が2012年5月20日の4.5.2で、現行の17.1とは版が大きく離れています。17.1は公式リポジトリの拡張機能で日本語化します。

Tiny Coreをハードディスクにインストールするにはどうすればいいですか？

CorePlusのインストーラか、tc-install.tczを読み込んでからsudo tc-install.shを実行し、Frugalを選びます。カーネルとルートファイルシステムの2ファイルだけを置く方式です。インストーラのブートローダーはsyslinuxとextlinuxだけなので、UEFI専用機ではgrub2-multi.tczで自分で起動の設定を組みます。

関連記事

• Arch LinuxのISOをUSBに書き込む手順｜dd・Rufus・Ventoyの使い分けとインストールまで
• セキュアブートとは？UEFIが署名でOSの起動を守る仕組みと有効化・確認・サーバー運用まで実装目線で解説
• Linuxのスワップ領域(swap)とは｜確認・推奨サイズ・vm.swappinessの設定を実コマンドで解説
• Linuxのバージョン確認：OS確認コマンドの早見表とos-release・unameの使い分け
• Raspberry PiでUSBメモリを使う方法｜公式Flash Driveの仕様・USBブート設定・fstab自動マウント